, Brian Pontarelli [EMAIL PROTECTED] wrote:
The API has yet to be solidified and there are a few things that I'd
still like to discuss and possibly change in that regard. My main goal
is to ensure backwards compatibility in the convention plugin API.
My thinking is like
opposed to half way through the 2.1 lifecycle. I'd also like to see a
change
to actrionError and actionMessage handling which removes the need for the
store interceptor for redirects, but I know that's something that's in
the
very early stages of thought.
That would be great. This should
Just some additional thoughts on this front... It seems like most
frameworks are heading in very similar directions now. They are all
getting lighter, faster, and better at selecting and manipulating
elements. I'm in favor or having some AJAX functionality baked, but I
have never found it
Dave Newton wrote:
--- Al Sutton [EMAIL PROTECTED] wrote:
Is there a list of gotchas for a 2.0 to 2.1 migration?
One was started at
http://cwiki.apache.org/S2WIKI/troubleshooting-guide-migrating-from-struts-20x-to-21x.html
There are more that should be added to this page. I'll try
Hehe. The changes from 2.0 to 2.1 are completely incompatible, so this
change is minor in comparison. if we were to use the commonly accepted
versioning scheme of major vs. minor releases, 2.1.x would eventually
become 3.0 when it goes GA. So, I say make all these break everything
changes
Don Brown wrote:
But don't you see, if we used the more traditional 1.0-alpha-1 -
1.0-beta-1 - 1.0-rc-1 - 1.0 then we could produce releases that
drastically changed the API within a single version. As it is now,
there could very well be huge changes from 1.0 to 1.0.1 because every
release gets
Don Brown wrote:
On 2/22/08, Brian Pontarelli [EMAIL PROTECTED] wrote:
Hehe. The changes from 2.0 to 2.1 are completely incompatible, so this
change is minor in comparison.
I disagree with that statement. For Struts 2 users, the changes are
only minor. I think you feel them more
Don Brown wrote:
On 2/22/08, Brian Pontarelli [EMAIL PROTECTED] wrote:
Here's an example... The XWork configuration API changed to the builder
pattern. This is probably a good thing, but required any plugin using it
to make significant changes and re-compile. This change wasn't
Don Brown wrote:
Here are my two points:
1. Our current versioning scheme requires patch versions for all
releases, regardless of quality
2. We need to be able to do alpha releases to get new, experimental
features into the community for testing
These two points, put together, will
Don Brown wrote:
On 2/22/08, Brian Pontarelli [EMAIL PROTECTED] wrote:
These two points, put together, will necessarily result in a 2.1.0
release that is drastically different than 2.1.1. I just don't see
any way around that.
Tooling can solve this issue.
How? As I said
Don Brown wrote:
Yes, you are missing my original point #2 - We need to be able to do
alpha releases to get new, experimental features into the community
for testing. I need a way to create an alpha release for 2.1 to hand
off to our community for feedback, but if all releases require a
unique
Jeromy Evans wrote:
Hi Brian,
I shared your frustration when I moved a plugin from 2.1.0 to 2.1.1.
Initially I was taken-aback by the significance of the changes to the
PackageConfig and ActionConfig that broke uses of MockConfiguration. I
didn't expect such a large change between minor
schrieb Brian Pontarelli:
Don Brown wrote:
I've cleared all but a couple issues out of Struts 2.1.1, so I think
we are ready for a release. The only kinda blocking issue is the
portlet tests failing, but that seems to have something to do with the
setup, not our portlet code, so we could even
Don, on the subject of XWork releases, I should have made this a
blocker, but this bug needs to be closed and I have a fix ready, just
don't have commit access. The patch is also in the bug if you want to
take care of it:
http://jira.opensymphony.com/browse/XW-599
-bp
Don Brown wrote:
Oh,
If convention-plugin is not bundled with the next release, people will stick
to the codebehind plugin. Last time I checked there was no smarturls for
2.1.x as well - so there is really not much choice.
(compiling from the sandbox is no option for most users)
You are probably correct.
The API has yet to be solidified and there are a few things that I'd
still like to discuss and possibly change in that regard. My main goal
is to ensure backwards compatibility in the convention plugin API.
My thinking is like this:
upgrading from [today's convention-plugin] to [final
Don Brown wrote:
I've cleared all but a couple issues out of Struts 2.1.1, so I think
we are ready for a release. The only kinda blocking issue is the
portlet tests failing, but that seems to have something to do with the
setup, not our portlet code, so we could even punt that one.
Any
I've been trying to catalog all of the cases where OGNL exists and where
it can be replaced. I'll sometime in the next few weeks to really work
on this and I'm hoping that we can replace OGNL from all developer
facing locations and completely standardize on EL. I think most folks
would be in
Newfield wrote:
Brian Pontarelli wrote:
I've been trying to catalog all of the cases where OGNL exists and
where it can be replaced.
Since different ELs specify different mechanisms to state this is an
expression to be evaluated, I wonder what we should do about the
delineating characters %{/} vs
Al Sutton wrote:
Guys,
One of the things that really gets me is the loss of action messages
and errors when using anything other than the default result type.
imho given that post and redirect is probably the most common pattern
for form handling we should allow messages to be passed on via
Sounds good to me. Makes it clear what is requires for the plugin.
-bp
Antonio Petrelli wrote:
Hi all,
in a previous thread:
http://www.nabble.com/-s2--Assembly-build-%28was-svn-commit%3A-r604801-%29-to14374597.html#a14374678
the question of separation of core libraries from the plugins
I'm gonna try and much a list of a areas that OGNL touches today so we
have good context about the full stack.
-bp
Tom Schneider wrote:
Unfortunately, I haven't had much (any) time to work on s2 at all
since December. Feel free to poke around and see how far you can get.
Tom
Brian
Just to preface this email, I've never been a big OGNL fan...
Okay, I'm updating everything to 2.1.1 and the new convention plugin and
realized a major change from 2.0.9 to 2.1.1 is that the struts tags no
longer accept JSP expressions, which has caused some major headaches. I
could change
Tom Schneider wrote:
Brian,
I worked on Unfied EL a bit towards the end of last year:
http://cwiki.apache.org/S2PLUGINS/unified-el-plugin.html I was able
to get it working for basic expressions, but it is nowhere near ready
for production. It would need a lot more coding/testing before it
Those are for base classes for testing. JCatapult solves this problem
with a separate JAR called jcatapult-core-test.jar, which is along the
same lines as a new maven project as you mention. Another way is to
remove the base class and provide test helper toolkits. JCatapult also
does this in
Piero Sartini wrote:
The results should be the same as smarturls, codebehind, etc. In your
case they should be login-success.jsp or login.jsp and
register-success.jsp or register.jsp. If you turn on some fine or finest
logging in the convention package it should print out the results it is
and not needed to
copy any spring- jars into the webapp.
Al.
- Original Message - From: Brian Pontarelli
[EMAIL PROTECTED]
To: Struts Developers List dev@struts.apache.org
Sent: Tuesday, January 15, 2008 11:54 PM
Subject: Re: Spring dependancies
I'm more in favor of removing any
Al Sutton wrote:
Are we going to bump the spring dependencies to 2.0.8 (or possibly go
for the 2.5 series) for S2.1?
Al.
P.S. (yup, still working on the test problem, just wondering if it's a
problem in spring-mock).
I got bit by this dependency today and I'm wondering if it makes sense
Anyone know the answer to this. I have created an
HttpServletRequestWrapper and changed the getRequestURI and
getServletPath methods in order to invoke a different Struts action.
However, I'm getting an XWork stack trace in the ValidationInterceptor
on a variable that is injected by Guice.
Figure out that NPE. It was an issue with my ObjectFactory not calling
super.injectInternalBeans() method to inject using the XWork container.
-bp
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
this, and we could
try to convince the maven guys into doing some kind of sping-xxx-2.0
repository link which pointed to the latest 2.0.x release :)
Al.
- Original Message - From: Brian Pontarelli
[EMAIL PROTECTED]
To: Struts Developers List dev@struts.apache.org
Sent: Tuesday, January 15
Thanks for trying all this out! This issue is that you are probably
loading too many classes into the JVM and the perm size is being filled
up and causing the JVM to blow chunks. This happens to me as well when I
forget to setup the excludes correctly.
Unfortunately I have a specific use
I really like the @Action annotation to map urls to the methods.
Excellent. I'm not 100% on them myself yet, but the fact that you like
them helps convince me some more. ;)
But its not clear to me how the results are choosen.
If there are 2 methods in the class UserAction:
:
That's great news, Brian. I'll give it a try on the JPA MailReader,
which is using the CodeBehind plugin right now, and see if it's, well,
plug and play :)
-Ted.
On Dec 29, 2007 12:41 AM, Brian Pontarelli [EMAIL PROTECTED] wrote:
I have the first rough version of the convention plugin
Don Brown wrote:
On Jan 3, 2008 5:44 AM, Brian Pontarelli [EMAIL PROTECTED] wrote:
What is the policy for Struts committers getting access to XWork? While
updating the convention plugin I had to change a few things in XWork and I
want to make sure that they get committed to trunk before I
If the codebases are to remain separate, I'd like to suggest that all
Struts2 committers are added to XWork. The reason that I say that is the
codebases are so coupled. If you look through comments in XWork, you
start to see more references directly to Struts2. Struts2 won't function
unless
Frank W. Zammetti wrote:
Adam Hardy wrote:
I don't know the JSF architecture with its page/component state
saving, Frank, but I don't think my proposition is along those lines
(with state saving).
I'm no JSF expert either frankly, but I was basing my thought on the
part where you said you
What is the policy for Struts committers getting access to XWork? While
updating the convention plugin I had to change a few things in XWork and I
want to make sure that they get committed to trunk before I start using the
convention plugin on projects. I have a few bugs open, but it could take a
Dave Newton wrote:
--- Brian Pontarelli [EMAIL PROTECTED] wrote:
- The preparation logic should ONLY be called when the form is rendered.
If I'm remembering correctly, any action that implements Preparable is
called via the interceptor chain during all submissions, including a
valid form
However, this still requires some composition or inheritance to support
multiple actions using the same preparation right?
-bp
Musachy Barroso wrote:
What I do is that I create an input map to the input method on the
same action class for which validation is failing. That method is
empty
It seems like this is a variation on the Preparable theme. I went
through this decision process 9 months ago and decided to use the
s:action tag to prepare my forms, mostly for lack of any other solution.
A few more things I ran into that I wanted and could only achieve with
the s:action
-
My requirements specify a mechanism that allows for:
- caching of lists (countries again in ApplicationScope for example)
- parameterization (e.g. a list of codes allowed in a particular
category - requires the categoryId)
- localization of dropdown beans (i.e. country names)
I handle the
Adam Hardy wrote:
Brian Pontarelli on 28/12/07 16:09, wrote:
My requirements specify a mechanism that allows for:
- caching of lists (countries again in ApplicationScope for example)
- parameterization (e.g. a list of codes allowed in a particular
category - requires the categoryId
Adam Hardy wrote:
Brian Pontarelli on 28/12/07 18:12, wrote:
In an ideal world I would be happiest to retrieve dropdown lists in
my Actions, but there is a clear separation between the Actions and
the JSPs, whose dropdown list requirements don't map one-to-one to
the Actions.
So I turned
I have the first rough version of the convention plugin checked into the
sandbox. Feel free to take a look. I haven't completed the unit tests
yet, but I did get most of the Javadoc updated and added all the new
features and support that was discussed.
The most major change I'm trying to
Now that my emails appear to be going through... Here's one of the two
emails that were lost last time.
Hey, just wanted to ping the list and see if anyone else is having some
concerns about the compatibility between versions of XWork and S2? I've
been upgrading a plugin from 2.0 to 2.1 and
Here's the other one
Since I don't have access to that code base and most of the committers
are on this one as well, can someone update all the new Builder objects
to provider getters and setters for all of the contained entities? For
example, the PackageConfig.Builder doesn't allow me
I've been trying to send out some emails to the list over the past
couple of days and I think they were all being dropping by GMail's SMTP
server. However, I think I've got it working again and wanted to send a
test prior to resending the old emails.
So, this is a test, only a test. ;)
-bp
One thing I noticed that I thought might be a good idea for session
safety was to move the flash Map from the session to the request on the
first usage of that scope. That way the flash is not there any longer,
in case of failures.
-bp
Tom Schneider wrote:
Actually, we've done a little
This is one of the founding principles that we put into JCatapult. It
uses Guice, which is pretty good for DI and Hibernate for JPA. JCatapult
uses a Filter to implement open session in view using Guice and it works
well. An interceptor could work for Struts only applications as well.
Don Brown wrote:
Since the commit for this feature involved a rather large XWork change
(properly immutable configuration objects [1]), I decided to commit
what I have and discuss the next steps.
First, due the aforementioned fix [1], Brian, your SmartURL's
migration work will probably be most
As long as it's a deprecation and not deletion, I think it will be
fine. i.e. in 2.1.x you can configure the app to use the old mechanism.
The only other (really small picky thing) is the name codebehind.
What I see Brian doing to providing mapping and configuration. When I
think of
3. A new @ActionMethod annotation for the codebehind plugin that
declares a method as callable
Does it make sense to collapse the SU ActionNames and ActionName
annotations into this new annotation? This annotation could provide
additional parameters to control the URLs for the method. If
I'm going to start working on the SmartURLs port. Here's what I'm planning:
1. Deprecate all the current codebehind annotations and classes
2. Create a new package named org.apache.struts2.plugin.codebehind
3. Move the SmartURLs classes over (simple re-package)
4. Move annotations into
I'm not 100% on the specification, but isn't this case what the delayed
evaluation is for?
-bp
Adam Hardy wrote:
Oh I see. The JSP standard specifies real-time expression evaluation
with EL when declared in the TLD for evaluation by the servlet
container, and OGNL is only evaluated by tag
Tom Schneider wrote:
I agree, I think it would be interesting to create a plugin that gives
us a seamless full stack: Struts2/Spring/JPA or Struts2/Guice/JPA.
As an aside, I've been working on a framework originally called Vertigo
and now called JCatapult (jcatapult.org) that is a full stack
SmokeTheSun wrote:
Hi,
Iam working in Struts1.2 application development. In that i want to restrict
direct access(through URL) for jsp pages or by calling .do action.
Specifically unauthenticated user must not access any pages.
Can you give the idea(s)..
Thanks,
Please ask this
The case I know of is anytime an OGNL expression is the value of a JSP
EL expression that the user has control of. This could be in the
session, request, or context from what I can think of. Usually it is a
parameter that is being passed in like this:
Andrea Vettori wrote:
Already posted on user list but maybe more appropriate here...
Hi,
It's long time I was away from this list.
I've found with big surprise that JSP EL is not available in S2 tags
anymore. I've looked at the release notes and found it was because of a
security problem
I think it would be feasible to pull the engine out and use it and then
attempt to put it back in. The key would be that at the end of the road
the next JSP specification dictates a pluggable JSP engine and an
API/configuration for plugging them in. Anyone have any experience with
Jasper?
Well, I was planning on checking out the next JSR, but jcp.org is down.
I'll check back later. If anyone from Sun is on this list, might want to
email the folks that manage that site and let them know it is toast
right now.
-bp
mraible wrote:
I don't think their implementation would be
Here are my thoughts:
AFAICT, the questions then become
* Which Result annotation syntax to support?
** CB uses a .class reference, SU uses a string setting that
corresponds to the Result name.
** CB uses value where SU uses location.
SU because it provides more flexibility with
Piero Sartini wrote:
Am Montag, 19. November 2007 18:55:43 schrieb Brian Pontarelli:
Hopefully that helps clear things up somewhat. If not, feel free to ask
more questions.
Thanks for your detailed answer, I do understand the issues with JSP much
better now.
Excellent!
Oh
I prefer type safety wherever possible, but the annotation should
probably support both for the rresult type. As for value vs location,
value is more convenient since you can just do:
@Result(/foo.jsp)
for results that use the default result type, and as mentioned,
location isn't the param
Musachy Barroso wrote:
Yep. I fall into that category. How else can you build reusable
components in Struts2? I'm still waiting for the JSP spec is fixed to
support everything from JAR files or modules and make JSP usable outside
J2EE container contexts
is that ever going to happen? (I
Piero Sartini wrote:
Am Freitag, 16. November 2007 23:04:37 schrieb Brian Pontarelli:
Yep. I fall into that category. How else can you build reusable
components in Struts2?
Could you please explain why this does not work in s2? I need to build such an
application and was under
Ted Husted wrote:
On Nov 13, 2007 9:00 AM, Tom Schneider [EMAIL PROTECTED] wrote:
And who says that Struts 2 devs recommend Freemarker? I sure don't. :)
Tom
It's true that there are quite a few hardcore Struts 2 teams that use
FreeMarker or Velocity (for good reason). But, the Apache
Thanks Brian, I can't break this version :-)
Excellent!
I still have the /an/arbitary/url/index issue which is very annoying
but acknowledge its present in non-smartURLs apps too. Unfortunately
setting the alwaysSelectFullNamespace flag doesn't entirely avoid it.
It generates a correct
Tom Schneider wrote:
On 11/6/07, Don Brown [EMAIL PROTECTED] wrote:
Type conversion isn't tied to OGNL in 2.1. XWork has a new API
(copied from OGNL) to abstract type conversion. Of course not all
EL's support type conversion in the same way, so there may be issues
down the road. i18N
Brian Pontarelli wrote:
Okay, I reproduced this pretty easily. The environment differences
didn't matter. The /missing rendering /index is due to the default
handling of missing actions that is performed by Struts/XWork I
think. I'll have to figure out exactly which interceptor does
Okay, I reproduced this pretty easily. The environment differences
didn't matter. The /missing rendering /index is due to the default
handling of missing actions that is performed by Struts/XWork I
think. I'll have to figure out exactly which interceptor does this,
but I'm not a big fan of
Inspecting the HTTP requests:
update returns a 404 with an iframe referencing /missing
the get of /missing returns a 302 containing the index page
subsequent requests are successfully performed within the /missing
namespace
ie.
http://localhost:8080//missing/edit?id=0
Note the double / as
Inspecting the HTTP requests:
update returns a 404 with an iframe referencing /missing
the get of /missing returns a 302 containing the index page
subsequent requests are successfully performed within the /missing
namespace
ie.
http://localhost:8080//missing/edit?id=0
Note the double / as
Ted Husted wrote:
On Nov 5, 2007 1:44 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
Okay. The example is in the SmartURLs repository:
http://smarturls-s2.googlecode.com/svn/trunk/apps/crud-example/
Are you using a modified TLD? When I tried to run it in Eclipse,
Tomcat complained
Ted Husted wrote:
On Nov 6, 2007 6:58 AM, Ted Husted [EMAIL PROTECTED] wrote:
Of course, for SmartURLs today, in order to use action validation we
have to use the thin approach. The validation annotations for multiple
methods are glommed together in 2.0, and SmartURLs doesn't seem to
pickup
Sorry, forgot to commit those changes. They are in now.
-bp
Jeromy Evans wrote:
Brian Pontarelli wrote:
Brian Pontarelli wrote:
Okay. That should be finished. It was somewhat tricky because the
XWork runtime configuration returns a valid ActionConfig for any URL
that ends in a / if you
we GET add or edit and invoke Prepare,
and then how do we POST to save, update, or delete, and invoke Prepare
if validation fails?
On Nov 2, 2007 3:30 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
I think my simple CRUD example will shed a lot of light on my methods,
but here's a rough run down
Ted Husted wrote:
On Nov 1, 2007 4:10 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
s:hidden name=[EMAIL PROTECTED] value=EUR/
s:textfield key=child.allowance/
c:hidden name=[EMAIL PROTECTED] value=MM/dd//
s:textfield key=subscription.expireDate/
Is the use case that these facts
, thoughts, mods, etc) is welcome!
-bp
Brian Pontarelli wrote:
I didn't get very far with the example application. But I should be
able to get that finished today. That application should illustrate
exactly how I've been doing things lately. The situation you brought
up is exactly the same one
How will this handle key collisions in large projects? Or collisions
with resources on the classpath that aren't easily modified?
-bp
Ted Husted wrote:
I'm looking at https://issues.apache.org/struts/browse/WW-809 which
would let us load message resources by designating a package with a
Chris Pratt wrote:
On 11/1/07, Brian Pontarelli [EMAIL PROTECTED] wrote:
I've also built 3 components using it, a CMS component, News component
and User component. All of these components are being used in the above
sites.
If you don't mind my asking, what CMS system did you use
Jeromy Evans wrote:
Brian Pontarelli wrote:
Jeromy Evans wrote:
While on the topic, with respect to defaults/exceptions etc, can I
ask the specification addresses how invalid URLs are handled. In
the current implementation (0.18) invalid URL's return (unexpected?)
success results
Hmmm.. Why are you using the J2EE configuration? The key is
that smarturls will automatically redirect to / and you can just add a
/WEB-INF/content/index.jsp or an action and those can redirect or
forward or whatever. Is this something we should handle because there
are cases you
Ted Husted wrote:
Just to follow up, I tried most of these using the 0.18 MailReader
using a .do extension mapping.
The result were the same, so long as index.do is appended to the end
of each of the URLs.
Without extension-mapping, evidentially, it tries to seek /index, and
then falls back
Ted Husted wrote:
On Nov 2, 2007 1:52 AM, Jeromy Evans [EMAIL PROTECTED] wrote:
My case can be replicated in the MailReader however by adding a no-op
IndexAction in root namespace and removing the default-action-ref.
The use-case for the default-action-ref is localization. By using a
Ted Husted wrote:
On Nov 1, 2007 10:21 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
I have written ~10 applications to date using it:
Yes, but we also need public example applications that demonstrate a
range of workflows.
Definitely.
If we want to mark something GA, it's
Ted Husted wrote:
On Nov 1, 2007 5:02 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
I think there are two changes I'm going to make:
1. Remove smarturls.action.packages and replace this with
smarturls.action.package.identifiers, which is the list of identifiers
that package names must
On the topic of properties and localization, I'd like to figure out a
method for handling this stuff without actions but still associating it
with the action or xwork-package.
The struts.custom.i18n.resources setting will find the specified
properties file without an Action class.
But,
Ted Husted wrote:
On Nov 2, 2007 2:50 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
I've completely moved away from methods and bangs. It makes the code
more readable, and maintainable in my opinion and it reduces the
learning curve considerably.
What do you do about use cases like
Ted Husted wrote:
On Nov 2, 2007 12:20 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
Hmmm.. Why are you using the J2EE configuration? The key is
that smarturls will automatically redirect to / and you can just add a
/WEB-INF/content/index.jsp or an action and those can redirect
Ted Husted wrote:
On Nov 2, 2007 12:09 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
Ted Husted wrote:
Just to follow up, I tried most of these using the 0.18 MailReader
using a .do extension mapping.
The result were the same, so long as index.do is appended to the end
of each
Oops, wrong saying. Meant I See not Roger Wilco. Too much emailing
today. Almost time for beer!
-bp
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
returns
Ted Husted wrote:
Maybe we need the system to look for Action.properties even when there
isn't an Action.class.
On Nov 2, 2007 3:18 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
Of course, but I want to localize the messages to the correct package or
the result directory. Really
Antonio Petrelli wrote:
2007/11/2, Brian Pontarelli [EMAIL PROTECTED]:
Oops, wrong saying. Meant I See not Roger Wilco. Too much emailing
today. Almost time for beer!
It seems that you already had a pint :-P
Ah, Struts Ale. Nice hops with a smooth taste. When you add a little
First, just wanted to cover the plan quick. I was planning on merging
the SmartURLs code into the existing codebehind plugin tomorrow and
ensuring everything is correctly in the new packages and that the old
annotations are correctly deprecated. Is this still how we want to move
forward?
So, just wanted to toss this into the mix and see what you all thought.
Here's the issue I had:
Vertigo has a Money object that is a value and currency. I wanted to set
the value from a form. I wanted the currency code to be definable for
that specific form element. Oh, and Money is
Don Brown wrote:
On 11/2/07, Brian Pontarelli [EMAIL PROTECTED] wrote:
First, just wanted to cover the plan quick. I was planning on merging
the SmartURLs code into the existing codebehind plugin tomorrow and
ensuring everything is correctly in the new packages and that the old
annotations
Don Brown wrote:
On 11/2/07, Brian Pontarelli [EMAIL PROTECTED] wrote:
I think we might have slightly different ideas, but in general I imagine
everyone is pretty much inline and flexible enough to accept ideas from
others. I'll bang out the spec today and tomorrow and then see where we
feel kind of uncomfortable
with adding yet another syntax.
musachy
On 11/1/07, Brian Pontarelli [EMAIL PROTECTED] wrote:
So, just wanted to toss this into the mix and see what you all thought.
Here's the issue I had:
Vertigo has a Money object that is a value and currency. I wanted to set
Ted Husted wrote:
On Nov 1, 2007 5:02 PM, Brian Pontarelli [EMAIL PROTECTED] wrote:
So, if I bang out this specification, which would include the existing
functionality with the changes above and a few other things I want to
add in terms of features (i.e. searching / interceptors / defaults
101 - 200 of 282 matches
Mail list logo
