Re: SpringMVC articles
I know someone who might have just that answer… ;-) On Nov 28, 2011, at 10:24 PM, Frans Thamura wrote: > anyone read this? > > > http://www.theserverside.com/news/thread.tss?thread_id=63283 > > any comment for S2's future and direction. > > > > -- > Frans Thamura (曽志胜) > Chief of Advisory > Meruvian. > Integrated Hypermedia Java Solution Provider. > > Mobile: +628557888699 > Blog: http://blogs.mervpolis.com/roller/flatburger (id) > > FB: http://www.facebook.com/meruvian > TW: http://www.twitter.com/meruvian / @meruvian > Website: http://www.meruvian.org > > "We grow because we share the same belief." > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Roadmap for 2.3
In development mode, using XML, you can also make real-time production configuration changes without needing to restart :-) /Ian On 03/15/2011 07:27 AM, Frans Thamura wrote: > we find also using old xml is easier thatn @Action/@Result > > what happen if we wanna to change the result from velocity to jsp, to jasper > > the new one cannot > > F > > On Tue, Mar 15, 2011 at 6:25 PM, Maurizio Cucchiara < > maurizio.cucchi...@gmail.com> wrote: > >> Johannes, >> I don't know, I'd prefer to keep the core the more slight as possible >> (but my opinion could be biased cause I am an old fashion XML coder :) >> ) >> >> >> On 15 March 2011 11:03, Johannes Geppert wrote: >>> Only a thought, what are you thinking about moving the convention plugin >> into >>> core? >>> >>> Many People don't know the convention plugin and offen i hear that >> Struts2 >>> is >>> an old fashion XML configuration MVC Framework. >>> >>> Johannes >>> >>> >>> >>> -- >>> View this message in context: >> http://struts.1045723.n5.nabble.com/Roadmap-for-2-3-tp3609943p3695351.html >>> Sent from the Struts - Dev mailing list archive at Nabble.com. >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> For additional commands, e-mail: dev-h...@struts.apache.org >>> >>> >> >> >> -- >> Maurizio Cucchiara >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Struts2 jQuery Plugin - Logo
I haven't looked at the code for the jquery plugin yet, but I can offer some insight into the problems with the dojo integration. At the time of writing, dojo was the most mature framework out there. The problems we encountered was with JS programming model that dojo used as well as a strong integration due to the API, which caused problems when the API changed. This led to problems upgrading, and the code going dead. There were also always problems explaining how the use, and debug, the tags. Overall, not a great solution. I'm glad someone stepped up to add ajax functionality to the framework (since Philip was all words and no action :-)). I believe this is something that we need for greater adoption (something I've spoken to Ted about in the past). What I would want to make sure of, is that the integration is more loosely coupled than the original dojo integration (once again, not looked at the code). I think this is important to avoid the problems of the past. But I do agree with Rene in that there is a much better understanding of ajax and ajax frameworks today, which will also help us, especially using jquery as a base technology. /Ian Rene Gielen wrote: > That is what I also regognize from the disussions a while ago. > > We all know that the Dojo tags turned out as a nightmare. Dojo looked > promising back in these days, with all it's supporters and some good > solutions when there were only few alternative frameworks around. > Nevertheless, not only the programming model was hard to get and to > understand, also the API was in constant flux without ever coming to a > stable state for years. Today we can consider Dojo as the biggest loser > in the JS framework run. > > jQuery nowadays has turned out to be stable both in functionality and > API stability, compact, fast, mature and easy to understand. It can > really be considered as _the_ JS/AJAX framework besides Prototype, and > the adoption is overwhelming. Many Java web delvelopers, including a > couple a S2 community members I know of, have already incorporated plain > jQuery into their projects and built up a good knowledge about it. Most > of our "competitors" incorporate it either directly or via mature > plugins, have a look at Myfaces, Richfaces, Icefaces or Wicket. > > My feeling was that there was a consensus that jQuery would be the way > to go if we wanted to go provide a good AJAX solution, but we had not > enough resources to build a plugin from scratch. Now Johannes stepped up > and presented a complete plugin, and IMO we should see this as a great > opportunity. If we don't want to fall terribly behind the other web > frameworks, we need a decent and state of the art AJAX support - pure > Web 1.0 interfaces are more and more going away, and people tend to > judge a web framework for consideration in their projects also by it's > AJAX capabilities - e.g. when Rainer and I did some Struts 2 talks the > last couple of months for JUG Cologne, that was a very clear feedback we > got from many people in the audience. > > Once the plugin is there, I don't see why it would be any harder to > maintain than oher external library plugins we have, let's say Spring or > Sitemesh or what not - especially since I suspect a lot of S2 developers > and community members are using jQuery on regular basis and will be able > to help with their experience. Also, we don't have to fear an API > breaking with every minor release as we had with Dojo, which made > maintaining it that hard. > > - René > > Musachy Barroso schrieb: > >> A while back we said that we would remove the "ajax built in" from the >> feature list if we didn't find a replacement for the Dojo tags. Some >> work was done on a jquery plugin by Wes, and I think I dropped 1 line >> of code somewhere, but is hasn't got far, but we do want simple ajax >> tags to replace the dojo ones. >> >> The way I see it, and I thought we were all in the same page, is that >> we should have very simple ajax tags for the simple use cases, and not >> go beyond that. The simple ajax tags is not the problem, the problem >> is the library that we used to implement it which ended up creating a >> bigger problem that it was supposed to fix. >> >> musachy >> >> On Fri, Jul 24, 2009 at 11:47 AM, Martin Cooper wrote: >> >>> Whoa. Before we go rushing off gung ho to include this as part of Struts >>> itself, shall we re-discuss the topic that, right now, applies to this >>> plugin just as much as to the Dojo tags? >>> >>> I mean, of course, the fact that we specifically decided that we didn't want >>> to support a specific AJAX library any more, as a part of the main Struts >>> distribution. We didn't want to get ourselves into a situation in which we >>> had a set of tags that relied on an external library that we would then be >>> expected to support. We didn't want to have another AJAX plugin as part of >>> Struts that a very small number, if any, of our committers could - and, >>> especially, w
Re: No Press?
Actually, who wants to do a quick email q&a with me? I haven't been following the news group as closely as I should, and I'd like to add more to the news post than what's on the release notes they're a little dry). Musachy? Ping me off-list. dusty wrote: > Strange I haven't seen any coverage of the 2.1.6 release. I even let the > TheServerSide.com know about it a few days ago and they still haven't run > anything. I find that kind of weak sauce, although that mag has been going > downhill a bit. But nothing on infoq.com either. I guess it seemed like a > bigger deal to me than to the rest of the world. > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: No Press?
I'll put something up on infoq later today or tomorrow. dusty wrote: > Strange I haven't seen any coverage of the 2.1.6 release. I even let the > TheServerSide.com know about it a few days ago and they still haven't run > anything. I find that kind of weak sauce, although that mag has been going > downhill a bit. But nothing on infoq.com either. I guess it seemed like a > bigger deal to me than to the rest of the world. > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Dojo plugin proposal(my last one I promise)
A few people have tried, but this was some time ago. I can't remember the problems right now, other than it was non-trivial. I agree with Martin that we shouldn't just dump the code expecting that someone else looks after it. Although, other than Musachy, I'm not aware of any of the committers working on this part of the code. Even in WebWork it's always been a feature that users try and then get frustrated with. No answers, just some comments :-) /Ian Dave Newton wrote: > I wonder if the plugin was on Google/etc. if more people would work on it or > try to upgrade the Dojo version? There's enough code in there that makes me > think a straight conversion to Dojo 1.0 is non-trivial, but I haven't looked > at it in awhile. > > I know I don't know enough Dojo to be very helpful, and my own needs aren't > related to Dojo, although I still think a common interface into multiple > Ajax/etc. implementations would be a good idea and would help with that > aspect of things. > > Dave > > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > > +1 - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Who's going to Devoxx conference, Antwerp?
Unfortunately not this year Rene Gielen wrote: > Probably the biggest European Java conference, Devoxx (formerly known > as Javapolis) is happening next week in Antwerp, Belgium. > > Rainer and me will be attending, and we were wondering if other Struts > fellows will be around... > > Regards, > - Rene > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Concerned Strutszien: A Manifesto
> To be sure, there *are* some cool things in S2. What I for one don't > see, and I've heard a similar feeling expressed by many as recently as > at The Ajax Experience earlier this month, is a clear, coherent vision > of how S2 lets me develop these so-called Web 2.0 applications better > than any other framework. What is there in S2 to truly excite Web 2.0 > developers in S2 as compared to other frameworks? That to me is the > fundamental question to be answered, and the fundamental reason S2 > doesn't have the uptake many feel it should. I hesitate to put it > this way because it seems potentially unfair, but I'll say it anyway: > it's almost like S2 is standing on the sidelines while the web > development world moves in a fundamentally different direction, and S2 > isn't keeping up as well as it needs to in order to be the success S1 > was. I would agree to this. I would also suggest that for all the core team (for me at least) there is limited time to commit to the project, and unclear feature direction. Regular releases come not only from a smooth release process, but also having enough new feature and bugs resolves to warrant it :-) With limited time to devote to a project, having cohesion on the features being worked on, and having multiple developers work on them to completion, seems like a better alternative than having everyone work on their "pet" feature, whenever they have time (that exponential decreases). Just my thoughts... /Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Struts 2 Starter Maven Archetype v2.0.11.2
+1 (non binding) - this has been a problem for a long time and I'm glad it's been fixed Wendy Smoak wrote: The Struts 2 Starter Maven Archetype v2.0.11.2 is available for review. Staging repository: http://people.apache.org/builds/struts/struts-archetypes/2.0.11.2/starter-m2-staging-repository Instructions for use: - http://struts.apache.org/2.x/docs/ready-set-go.html - http://struts.apache.org/2.x/docs/struts-maven-archetypes.html (...adjust version and remote repo as necessary.) Once you have had a chance to review this build, please vote: [ ] +1 Release it and update the docs! [ ] +/- 0 [ ] -1 This should not be released because... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 as JSR for Action Framework
I've also been thinking along these lines, starting about a year back when there was discussions around the convention plug-in. Although it was motivated more on a clean annotation implementation - as there seemed to be a good synergy between the JSR-311 annotations and what s2 could leverage (as opposed to defining new annotations). /Ian Don Brown wrote: Personally, I don't think Struts 2 has a strong enough API, ok, I _know_ Struts 2 doesn't have a strong enough API to be turned into a JSR, currently anyway. Bob did some work trying to define such an API, and is probably 80% of the way there, but I wonder if the technology has moved on a bit since then... For fun in a side project, I'm going back to pure Servlets and a simple template language [1] to better understand what a web framework really needs to provide. As I see the options now you have: * Rails/Merb/Grails - rapid development, scripting language base, solid best of breed stack (for Grails anyway) under the covers. On the other hand, using any of these to write a hello world war is something like 25 megabytes and a ton of dependencies. That is fine for shops that need to get something up quickly and are starting from scratch, but not for others. * JSF/Wicket/Tapestry - component development for swing/drag-and-drop folks, ability to wrap up complex bits into new components, usually nice tool support. On the other hand, their apps tend to not be RESTful and take you quite a ways from HTTP. Also, they usually involve a lot of server-side state management which can impact scalability and they sometimes rely on a Javascript to really work. Finally, each tends to really favor their one template language by design, limiting options down the road. * Struts/Stripes/Spring MVC - lightweight MVC frameworks with minimal dependencies, with a specific focus on the presentation tier. Easy access to HTTP features, not much to learn, can fit easily into most application stacks, and tend to be very RESTful. These frameworks tend to be fast, impose little requirements on the session, and work with most template engines. This idea of a JSR would be standardizing the third group, but I wonder if maybe the better direction to go is not a new API, but build extensions on JAX-RS [2]. To me, this group's niche is apps that need lightweight presentation engines a layer above servlets, but still very much "web-y". JSR 311 aims to make restful resources easy to build, which isn't far from restful web applications. Especially as more and more applications are starting to rely on client-side AJAX interfaces, the need for a solid RESTful backend only gets stronger. The storage of server-side state of the component frameworks becomes less important, and if you don't want the bulk of Grails, this approach may be attractive. For my day job, we need to build REST interfaces to our web apps, so we are looking to standardize on JAX-RS. Well, we also need a lightweight web framework for our plugin system, and if we are already using something like Jersey [3], it would be nice to be able to write web apps using the same technology. This use case is obviously very specific to our situation, but it is the direction I'll likely be taking in the next few months. Don [1] http://www.source-code.biz/MiniTemplator/ [2] https://jsr311.dev.java.net/ [3] https://jersey.dev.java.net/ On Fri, Aug 22, 2008 at 4:31 PM, Frans Thamura <[EMAIL PROTECTED]> wrote: hi all is it possible that S2 become part of JCP? java server action framework right now only component framework there any idea? -- -- Frans Thamura Meruvian Foundation Mobile: +62 855 7888 699 Linkedin: http://www.linkedin.com/in/fthamura Training JENI, Medallion (Alfresco, Liferay dan Compiere).. buruan... URL: http://nagasakti.mervpolis.com/roller/mervnews/entry/jeni_training_compiere_dan_alfresco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: S2 as JSR for Action Framework
Not that it's a particularly good metric, but I always thought the adoption rates were very slow. However, I'm always surprised how many companies are using s2 when I speak to people at conferences. Maybe no-one wants to admit it publicly :-) /Ian James Mitchell wrote: That's a hard question to answer. It's probably like politics. You'll get completely different answers depending on who you ask. On Fri, Aug 22, 2008 at 11:11 AM, Musachy Barroso <[EMAIL PROTECTED]> wrote: That's a good point, and I do have a question myself, how are we doing adoption-wise? Judging from the users mailing list traffic, I would say well. In any case, just better of talking about this on the user list rather than here. musachy On Fri, Aug 22, 2008 at 10:52 AM, James Mitchell <[EMAIL PROTECTED]> wrote: Let the marketplace decide. Just my $0.02 On Fri, Aug 22, 2008 at 2:31 AM, Frans Thamura <[EMAIL PROTECTED]> wrote: hi all is it possible that S2 become part of JCP? java server action framework right now only component framework there any idea? -- -- Frans Thamura Meruvian Foundation Mobile: +62 855 7888 699 Linkedin: http://www.linkedin.com/in/fthamura Training JENI, Medallion (Alfresco, Liferay dan Compiere).. buruan... URL: http://nagasakti.mervpolis.com/roller/mervnews/entry/jeni_training_compiere_dan_alfresco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- James Mitchell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "Hey you! Would you help me to carry the stone?" Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] S2: Subclassing plugins
I'm a little surprised that you can't do this now. Is the problem because of the order of loading the plugins during bootstrapping or the way the authors write the plugins, or something else? /Ian Paul Benedict wrote: Since plugins are a collection of classes and they are available to me on the class path, I should be able to subclass any of them -- and replace them. Imagine I like the functionality of one and want to add a bit more? Why can't plugins have protected methods that I customize? I don't want to redo all its work, but I do want to "replace" classes with my subclass. Paul On Sun, Jul 20, 2008 at 8:33 PM, Musachy Barroso <[EMAIL PROTECTED]> wrote: I don't see plugins as something that you extend, but more like something that you customize. If there is something that you need to modify on a plugin, then that should probably be an extension point in the plugin. Take for example the case of Codebehind and REST, with some small modifications Codebehind was modified so it could be "customized" by REST without having to extend it. I know this doesn't cover all the possible use cases. musachy On Sun, Jul 20, 2008 at 8:45 PM, Paul Benedict <[EMAIL PROTECTED]> wrote: When I want to extend a plugin, I unfortunately have to unpack the libraries and include them into my own web application. I use Maven's Dependency plugin for this. :-) It is the only way I know of getting a hold of the binaries without forcing them into plugin status. I see two ways out of this: 1) Refactor each plugin to be the code and a plugin jar wrapper. 2) S2 needs a way of saying which plugin NOT to load. Obviously the plugin jar is going to be in WEB-INF/lib. That's good enough to extend, if I have a way to stop it from registering. I wholly prefer #2. Other options welcomed. Paul -- "Hey you! Would you help me to carry the stone?" Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: environment awareness (project stage in JSF)
I've actually had to implement this type of feature in multiple enterprise applications. However, I would say that it's not knowing the environment, but being able to change configuration elements per environment that is important (for what I did, and in rails I think this is the most important elements). i.e. change the SMTP, temp file dir, admin user email address, etc. depending on whether you are testing locally vs. production. If developers are using spring, there is a way to load property files with a hostname extension (which is one solution) - but should we always expect users to be using Spring? The other question is being able to modify struts.property properties depending on env (i.e. devMode=true in development and never in production). /Ian Antonio Petrelli wrote: 2008/6/27 James Holmes <[EMAIL PROTECTED]>: http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature2 I like it. This is one of the features of RoR that I really found useful. Anyone else had thoughts of doing something like this for Struts 2? I hope that my answer is not a flamebait, but I think that this feature is pretty lame. I think that it can be easily implemented, for example with JNDI (like they did), or with a context param in web.xml, or whatever. Do we really need it? Moreover, I think that modifying behaviour of an application depending on where it is deployed is a bad idea. Sometimes it is difficult to figure out why bugs happen in production and not in our local environment. If we have different behaviour, debugging becomes a nightmare. About the example in the blog: Here is where ProjectStage comes in: If the current stage is Development and no h:messages is present in the view, we'll add one automatically for the user. If the stage is Production we'd take no action (assuming the user would have this all corrected - no need to try to modify the tree). Does it mean that, once in production, no message will appear? It's fantastic, I see a message in development and I forget to hard code it, because the framework puts one for me, and in production it does not appear, so the user will be clueless on what's happening. Just my 2 eurocents rant :-D Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Bring Convention plugin into trunk and deprecate Zero Config
I've spoken to quiet a few people that are already using zero-config in production. I understand that it was always experimental, but it was also solid and now used. I'd have to agree with Don (even though my vote is now non-binding) and vote +0 if the existing zero-config features are supported. /Ian Don Brown wrote: Has any work been done to support existing zero config applications with this new plugin? If not, I'd kinda consider that a blocker (-1) because a sufficiently flexible configuration system should be able to support multiple conventions. Also, someone will have to sign up to convert the REST plugin, which currently depends on the codebehind plugin. If backwards-compatibility and REST plugin migration are resolved, I'd vote +0 Don On Wed, May 14, 2008 at 1:39 PM, Musachy Barroso <[EMAIL PROTECTED]> wrote: With the addition of @IntereceptorRefs to the Convention plugin, it is now possible to do most of the action mapping using annotations. Also having 2 plugins to do the same thing is really confusing for users, so we should deprecate Zero Config (good thing is that it was always "experimental"). If you have had a chance to look at the Convention plugin, please vote: [+1] Move the Convention plugin to trunk and deprecate Zero Configuration plugin [-1] Leave it in sandbox. (reasons?) regards musachy -- "Hey you! Would you help me to carry the stone?" Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] A thought - next generation OSGi-based?
Maybe I'm overstepping my knowledge from fact, but I thought the benefit
of OSGi was that you could have completely different implementations
(i.e. PackageConfig) running on the same JVM, with OSGi providing the
classloading magic so that the implementations don't collide.
If this is the case, I don't think this would lead to versions in the
classname as you've shown below, but it may require the core S2/XWork
JAR to be further split to provide more modularity. Perhaps even down
to completely separate implementations.
My question with Don's proposal is with item #4. Is it new features of
the same webapp that use new APIs or new webapps that use the new APIs?
Option one is going to be hard, and may not be possible even with OSGi.
For option 2, I'm wondering if OSGi is overkill (i.e. would webapps be
separated enough via the container). A better question might be is it
the webapps that need to change the APIs they are using, or is it the
plugins?
/Ian
Brian Pontarelli wrote:
Yours and mine are the same because you still have implementations
inside Struts for some of the API interfaces. For example,
org.apache.struts2.config.PackageProvider (yeah, I did move this from
XWork to Struts for my example ;), will be an API interface that
applications can implement. Struts2 also implements this API.
Another case is a non-interface POJO like PackageConfig. This class
can be instantiated by app1 and then passed back to struts. Likewise,
app4 might instantiate a different version and pass it back. You have
to separate these into namespaces in order to compile Struts if the
versions of PackageConfig are fundamentally different.
If we take the concrete example of 2.0.* and 2.1 for PackageConfig,
one is mutable, the other is immutable with the Builder pattern.
However, they have the same package and classname. The issue is that
at compile time Struts needs to import and use PackageConfig. The only
way I know how to pull this off is extract a common interface (Java
interface that is - public interface IPackageConfig) and make adapters
OR to separate them into namespaces.
org.apache.struts.config.PackageConfig_2_0
org.apache.struts.config.PackageConfig_2_1
Then you can see the ensuing code inside Struts to deal with these:
org.apache.struts.config.ConfigurationManager_2_0
org.apache.struts.config.ConfigurationManager_2_1
And then you need some method of determining the version of the API
that the application is using and then select a configuration manager
based on that.
Now, there might be some type of tricks and things that OSGi can
provide to make this happen, but I'm not familiar enough with advanced
bundling and classloading to know how it would work. From what I
understand of OSGi, any bundle can only use a version of a dependent
bundle that is compatible with the version of that dependent bundle it
compiled against.
For example, if I compiled against log4j 1.0, I can use 1.3 because
they are compatible at runtime and compile time. However, I can't use
log4j 2.0 because the interfaces changed and things will blow up
nicely at runtime. What OSGi does provide is the ability to have one
bundle using log4j 1.x and another bundle using log4j 2.x in the same
VM. I'm not aware that they have gone any further than that.
Ian Roughley wrote:
Is this the case, or was the thinking more like:
- app 1
- api 1.0 --{
/ - app 2
Struts ---{
\ - app 4
- api 2.0 --{
- app 3
I think this is how I perceived it. I also agree with Brian that
there will be a burden on s2 to provide the necessary features for
all APIs, but I think it's less of a burden in this layout.
/Ian
Brian Pontarelli wrote:
Here's a few things I think about when considering API versioning:
1. How many implementors are there? It sounds like there will be one
- Struts2
2. Do you want to allow implementors to implement multiple APIs?
Sounds like yes.
3. How much is shared between APIs? Probably a lot.
From what it sounds like, and correct me if I'm wrong, you are
looking to do something like this:
API 1.0--\
|--- Struts2
API 2.0--/
If this is the case, it will require some interesting coding
tactics. Sun and IBM have some white papers on these types of cases.
OSGi will shield the two APIs from each other so there aren't any
conflicts, however, the implementor will have the unfortunate task
of implementing both. This becomes difficult without proper
structure at compile time because struts2 will need to implement
multiple interfaces from both versions and these interfaces might
overlap.
I've done some of this type of work before and in order to truly
break compatibility between 1.0 and
Re: [s2] A thought - next generation OSGi-based?
Is this the case, or was the thinking more like:
- app 1
- api 1.0 --{
/ - app 2
Struts ---{
\ - app 4
- api 2.0 --{
- app 3
I think this is how I perceived it. I also agree with Brian that there
will be a burden on s2 to provide the necessary features for all APIs,
but I think it's less of a burden in this layout.
/Ian
Brian Pontarelli wrote:
Here's a few things I think about when considering API versioning:
1. How many implementors are there? It sounds like there will be one -
Struts2
2. Do you want to allow implementors to implement multiple APIs?
Sounds like yes.
3. How much is shared between APIs? Probably a lot.
From what it sounds like, and correct me if I'm wrong, you are looking
to do something like this:
API 1.0--\
|--- Struts2
API 2.0--/
If this is the case, it will require some interesting coding tactics.
Sun and IBM have some white papers on these types of cases. OSGi will
shield the two APIs from each other so there aren't any conflicts,
however, the implementor will have the unfortunate task of
implementing both. This becomes difficult without proper structure at
compile time because struts2 will need to implement multiple
interfaces from both versions and these interfaces might overlap.
I've done some of this type of work before and in order to truly break
compatibility between 1.0 and 2.0, you need namespaces in order to
allow Struts2 to implement both. Otherwise you get naming conflicts
that cannot be resolved by the compiler. I've do things like this before:
org.apache.struts.api1.SomeInterface
org.apache.struts.api2.SomeInterface
This is the same interface, but breaks compatibility between the API
versions. Only by separating the namespaces will you be able to
implement both at compile time. I've also worked with other situations
like this:
org.apache.struts.api.SomeInterface_1_0
org.apache.struts.api.SomeInterface_2_0
What it comes down to is that if you are going to break compatibility
at the API level you need to actually create a brand new API. When you
look at it from this perspective, OSGi really isn't needed, just nice
to have. Since the two API versions are in different namespaces, there
aren't any collisions at compile-time or runtime, eliminating the need
for bundle separation.
Having done some of these types of solutions before, I can attest to
the pain that they can cause. They can also become complex to manage.
Which sorta leads back to my original statements about compatibility.
I'd much rather see something like this:
1. The APIs locked down
2. These APIs called Struts3
3. No APIs break compatibility until Struts4
Therefore, 3.0, 3.1, 3.2, etc are all compatible. Then when Struts4
start wanting to break compatibility, you branch Struts3, and start
breaking away on Trunk.
-bp
Don Brown wrote:
As I learn more and more about OSGi, I wonder if it might be the
solution to several big problems we seem to have at the moment: poor
reloadability and the lack of a solid API. With OSGi, you can drop
bundles in and out of the system at runtime, even running multiple
versions of the same bundle side-by-side, but the feature I'm most
interested in right now is how it would allow us to put in a proper
API while maintaining full backwards-compatibility.
Evolving a web framework is hard because apps tend to be written on a
specific version, and to migrate them to new versions has two
problems: development may not be continuously funded and the upgrade
may require too many changes to the application. On the other hand,
if you don't evolve your web framework, you quickly go out-of-date and
lose interest from new developers. In our case, despite being a
relatively new framework, we have legacy code around from 2004 that we
can't just remove, yet we want to provide an attractive, modern, clean
framework for new development.
The specific issue it hand that I've been thinking about is how to get
a proper API into Struts 2 yet keep backwards compatibility, and I
think OSGi might provide a solution. What about this:
1. Struts 2 and its plugins remain the way they are now - 100%
backwards-compatibility
2. An OSGi plugin provides the platform for the next generation of
Struts 2
3. A new API bundle is created, implemented by the underlying Struts
2 framework
4. Old apps can continue to write and deploy code against Struts 2,
yet new development can start to use the new API
5. Later, when we want to write API version 2, we create a new bundle
that runs side-by-side the old bundle, both implemented by Struts 2
Basically, OSGi would allow us to write a clean layer on top of a
framework, much like how Grails builds on Spring, but we get, as a
side benefit, all the architectural advantages of OSGi for free.
Furthermore
Re: [s2] Let's get out Struts 2.1.1
Dave Newton wrote: --- Musachy Barroso <[EMAIL PROTECTED]> wrote: On Thu, Feb 21, 2008 at 2:03 AM, Al Sutton <[EMAIL PROTECTED]> wrote: Before a GA release of 2.1 I'd ideally like to see dojo upgraded to the latest, greatest stable version, I have totally changed my position about the dojo plugin. I think Struts should have some ajax functionality for the most commom use cases, but I think we just picked the wrong ajax framework. Also my conclusion when the ajax code was ported from ww2 to s2. And I was really happy when you took over maintaining the code ;-) Yikes. The issue with the Dojo plugin (and any other, like my somewhat-waylaid jQuery plugin) is that I end up writing all the JavaScript anyway, and the tags don't help me very much in all but the *most* basic use-cases. The other conclusion I came to, about the same time as above. To take jQuery (which I've being working with a bit lately), even if you have a s2 plug-in/theme, there may need to be continuous updates or additions depending on the different plug-ins being used with the jQuery core. Also, with jQuery again, in some cases you will also need to take into account whether the page being returned is part of an ajax request itself. Jeromy is working on the YUI plugin and I will give it a hand, maybe that will be a better option in the future. The Microsoft YUI? :D Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mailing list archive
MarkMail baby http://struts.markmail.org/ -- Ian Roughley From Down & Around, Inc. Consulting * Training / Mentoring * Agile Process * Open Source web: http://www.fdar.com - email: [EMAIL PROTECTED] Dave Newton wrote: Is there an easy way to get the entire struts-user mailing list archive, potentially broken up by dates? (It's for research.) d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Libraries in JDK 1.4 distribution
Martin Cooper wrote: On Jan 14, 2008 10:05 AM, Ted Husted <[EMAIL PROTECTED]> wrote: It's true that we're volunteers, and any of us can walk away whenever we like, but it's also true that when we vote +1 on a GA, each voter is saying that he or she intends to help support the release. No, it's not. That is a myth that you have been perpetuating for several years now, but it's just not true, and quite frankly I'm fed up hearing it. The bylaws seem to disagree, from http://struts.apache.org/dev/bylaws.html - " The act of voting carries certain obligations. Voters are not only stating their opinion, they are also agreeing to help do the work." Although, to me, "helping to do the work" is a little ambiguous and different from "supporting the build".
Re: SmartURLs port
Don Brown wrote: Could you commit your version as a development branch, rather than to trunk? I'm using/improving Codebehind right now in some of the new features both in core and the rest plugin. I'd also like a chance to fully review the changes before we dump the old. On 12/6/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote: 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 I'm still not convinced this is a good idea, but as I said, I'll reserve judgment till the merge branch is ready. 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 "codebehind" I think of the code that looks up a result template following naming conventions. Although these may have been considered one-and-the-same, I think by separating them by names we can enhance both concurrently. i.e. rails scaffolding - introduce a plug-in that can generate JSP code by reflecting on the action
Re: [s2] extras-lib (was JUEL plugin (was Roadmap for the core taglib))
It's great that Tom is doing this work, and it wasn't my intent to put down the effort. I guess I was just trying to preempt given some of the OGNL threads. /Ian Tom Schneider wrote: LOL, I didn't know my efforts were going to cause such a raucous. :) Ted is correct--I started this on Saturday on a whim. At this point it is completely experimental--we have a long ways to go before it is even close to usable. However, I was able to execute a simple expression using my value stack, which for me, was a worthwhile accomplishment. I didn't want Don's work to abstract away the value stack to be completely wasted, we needed at least one other value stack implementation to truly test his changes. Don did good work, but there is still a lot of OGNLisms that have crept into the code over time. It would be nice to find and eliminate these Ian brings up a good point in that we'll have to decide how to handle some things like I18N/type conversion/method invocation. Not all EL's are created equal and OGNL probably is a little more flexible and powerful than most. Then even if we get all that working, what's the migration strategy? Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] extras-lib (was JUEL plugin (was Roadmap for the core taglib))
Chris Pratt wrote: On Nov 6, 2007 11:35 AM, Ian Roughley <[EMAIL PROTECTED]> wrote: Sorry to be a little behind on the thread, but what is the message that we are providing to user across different EL implements? Is accessing internationalization text and using custom type converters, for example, going to be the same for users for all EL's or different depending on which EL is used under the covers? Based on the two examples we have at the moment, they are different. But I don't think it's necessarily the job of an Expression Language to provide internationalization support. No - but my question was what's our message to users. "If you change EL's you have to update some/all the EL expressions as well as go through and change the interfaces for type conversion, etc. - or - are we going to try to abstract this a little for the user? For your comment, I am assuming you are saying the message is - changing the EL means changing everything the EL touches, and selecting an EL means making a choice on everything the EL touches, correct? It's purpose in life is evaluating expressions. (*Chris*) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification
If it were me, I'd finish the book using struts.xml, and go to work on a second edition as soon as SmartURLs goes to 1.0 (even if the first edition isn't done yet). Getting a couple of solid Struts 2.0 books out there is the best way to drum up marketshare for a Struts 2.1 edition. Bummer... mine already went to press (available Nov 26th), and I used XML and the basic annotations/code-behind. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] extras-lib (was JUEL plugin (was Roadmap for the core taglib))
Ted Husted wrote: On Nov 4, 2007 10:26 PM, Chris Pratt <[EMAIL PROTECTED]> wrote: On Nov 4, 2007 2:58 PM, Don Brown <[EMAIL PROTECTED]> wrote: As for the problem of so many combinations of plugins, I'm all for the proliferation of plugins, but do think we need to not ship with two plugins that solve the same problem. I believe Struts already ships multiple plugins that solve the same problem. The View and the File Upload problems each have multiple plugins. I think the whole point is choice, and I don't see any problem with shipping that choice as part of Struts. Ted has also championed a one-stop, "getting started" file that would contain a single solution to each of the problems (with the exception of the view), which I think takes care of the problem of confusing new users. But that's just one, non-committer's, opinion. (*Chris*) The tipping point for a one-stop JAR might be whether we break out the tags or not. Sorry to be a little behind on the thread, but what is the message that we are providing to user across different EL implements? Is accessing internationalization text and using custom type converters, for example, going to be the same for users for all EL's or different depending on which EL is used under the covers? /Ian
Re: Fixing theme inheritance
I have spend some time thinking about this problem - especially when I was working on the ajax code - but I can't come up with a good solution (or maybe its just I haven't thought about it enough). The problem is the bigger picture, and as I see it, is that you may want to re-use an entire parent template except for certain sections in the middle (say the ajax library-specific calls). How can this be achieved? The parent templates could look for other templates, or some other type of library file, but I think this would mean that a single template that is easy(ish) to read, would be split into multiple files making extending themes harder as well as understanding them. /Ian Ted Husted wrote: The problem seems to be that we need a volunteer who is eager to work on this feature. The patch was a start, but only a start, and the comments indicate that there is still a lot of work to do. -Ted. On 10/19/07, Aymeric Levaux <[EMAIL PROTECTED]> wrote: Hi, At this time there is no way to extend a theme in a good way. See https://issues.apache.org/struts/browse/WW-1328 It would be great to have this issue fixed for 2.1 as there is already a patch which looks good and this fix would allow much more possibilities for plugin development. -- Aymeric Levaux - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Goal - no experimental code in core for 2.1
+1 - Having to explain the exception or the configuration voodoo is always difficult. Don Brown wrote: With the latest refactorings in XWork that allow plugins to provide code that load Packages, I'd like to suggest that we make it a key design feature of Struts 2.1 that Core includes no code labeled "experimental". Here is what I imagine it would entail: 1. Move the zero conf code (annotations and code from ClasspathConfigurationProvider) into the codebehind plugin. 2. Move restful mapper into its own plugin There are two main general advantages of this from a user perspective: 1. Code from core can be fully trusted to be deemed of GA quality 2. Using zero conf and restful features become easier While the first one is pretty self-explanatory, the second makes sense when you think about how plugins work. Currently, to use the zero conf or restful code, you have to have the right jars, config settings, and follow poorly documented rules. If, for example, the restful code was its own plugin, you could drop the restful jar in and it would configure your application with the appropriate settings automatically - disable .action extension, enable slashes in action names, set the restful mapper, etc. Right now, it takes some voodoo magic to get restful and zero conf working right (especially together), even for me and I wrote most of it :( By moving the zero conf code into the codebehind plugin, we also make it easier to maintain, document, and use for developers. Also, it makes it easier for other plugins, like SmartURL, to provide an alternate zero conf implementation. A different, but related discussion, is how best to provide zero conf in Struts 2, and honestly, I don't see a clear solution yet. What is in core now is ok, SmartURL improves things, but other parts I don't like as much, so by putting them all on the same playing field, I'd hope we encourage innovation. Anyways, back to the main topic, I'd like to get all experimental code out of core. Any objections? Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Should tags be their own plugin?
Ah - ok. I think I was reading the "s" on tags and plug-ins :) So there would be possible 3 different tag libraries: (1) Non-Freemarker/OGNL JSP (2) Exisiting JSP/Freemarker/Velocity (3) Dojo/Ajax plug-in Each of which may or may not be in the same deployment JAR. /ian Ted Husted wrote: I don't think that the change would have any impact on themes. The proposed plugin would have all the same code, it would just be in a separate JAR, that people could either use (by default), or replace, or leave out all together. -Ted. On 10/5/07, Ian Roughley <[EMAIL PROTECTED]> wrote: What is the impact on themes going to be? Or is the consensus that themes aren't really used, and individualizing the themes into tags, with writing more HTML code by hand is the solution? Don't get me wrong - I have a love-hate relationship with theme's. I think they are nice for some things, but generally miss-understood and a cause of quiet a few problems. One of the biggest issues I've personally had, is there is not a good way to extend one theme from another (and not a good way of implementing a solution). /Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Should tags be their own plugin?
> I don't think anyone has suggested getting rid of Themes or > Freemarker, just making them optional for the folks that don't > need/want them. Right now, there's no way to use struts without > Freemarker, without writing your own tag library. Well - actually no. You can re-write all the theme files as JSPs and then change the extension in the struts.properties / struts.xml file. Then JSP template for the theme's would be used instead of Freemarker. It just hasn't been done, or has been done and not contributed back ;-) > We're just > suggesting adding choice, not removing functionality. > (*Chris*) > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [s2] Should tags be their own plugin?
What is the impact on themes going to be? Or is the consensus that themes aren't really used, and individualizing the themes into tags, with writing more HTML code by hand is the solution? Don't get me wrong - I have a love-hate relationship with theme's. I think they are nice for some things, but generally miss-understood and a cause of quiet a few problems. One of the biggest issues I've personally had, is there is not a good way to extend one theme from another (and not a good way of implementing a solution). /Ian Piero Sartini wrote: S2 without freemarker would be great: +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.1.0 Build/Release Plan
I think he might be on vacation. Musachy Barroso wrote: Any idea when that might be? I haven't seen Rainer on #struts for a couple of weeks :) musachy On 9/28/07, Antonio Petrelli <[EMAIL PROTECTED]> wrote: 2007/9/28, Ted Husted <[EMAIL PROTECTED]>: I'd like to propose 7 Oct 2007 as a tag date for the 2.1.0 version. If anyone would be interested in helping with the build, please don't be shy! Ted, sincerely I wish to wait until XWork 2.1 is released, so we don't have any snapshot dependency. Antonio
Re: ApacheCon Roll Call
I was hoping to, but it looks like I will miss it. /Ian Ted Husted wrote: I was just wondering who was planning on attending ApacheCon this year. I know Don has a talk on the 15th, and Mark and I have tutorials scheduled earlier in the week. Is anyone else going to drop by this year? How about the Monday/Tuesday Hackathon? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: Should I announce SmartURLs or wait?
Don Brown wrote: The generally accepted terminology for release numbering is MAJOR.MINOR.PATCH. Yes, Struts does things strangely, but that doesn't change how users expect things to work. Throwing in big features, and yes, I consider new annotations big features as they worm their way into user code, is not something I feel comfortable doing in a "third-level" release, or whatever we call it. In this case, the annotations will be likely redone for 2.1 anyways. A lot of it is my fault - they have been kinda thrown in there without systematic thought, and I had hoped we could fix that for 2.1. I'd hate to introduce new annotations only to deprecate them weeks later. My preference would be to wait as well. If for nothing else, to see how JSR-311 (RESTful web services) flushes out and whether we should adopt some of the structure of the annotations in Struts2. Has anyone looked into this JSR? I saw a presentation at Sun Tech Days the other day. I just need to find some time to see if it could be adopted to the annotations in s2 now :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help with the @Inject Annotation
I'm not sure that tag libraries are created by the object factory, if
this is the case, then the behaviour you are observing is correct (as
the annotations aren't checked and thus values not injected). You
should be able to track back the object creation in the code to confirm
this.
/Ian
Chris Pratt wrote:
I'm attempting to understand the @Inject Annotation and how it can be
used. I'm trying to create a tag library that needs to look up action
data, so following the pattern from the FormTag I added this methods
to my tag class:
private boolean enableDynamicMethodInvocation = true;
private Configuration configuration;
private ActionMapper actionMapper;
/**
* Inject a flag as to whether Dynamic Method Invocation is enabled
*
* @param enable "true" to enable
*/
@Inject(StrutsConstants.STRUTS_ENABLE_DYNAMIC_METHOD_INVOCATION)
public void setEnableDynamicMethodInvocation (String enable) {
enableDynamicMethodInvocation = Boolean.parseBoolean(enable);
log.debug("Dynamic Method Invocation Enabled {}",enable);
} //setEnableDynamicMethodInvocation
/**
* Inject the Struts Configuration for looking up the proper Action
*
* @param config The Struts Configuration
*/
@Inject
public void setConfiguration (Configuration configuration) {
this.configuration = configuration;
log.debug("Struts Configuration {}",configuration);
} //setConfiguration
/**
* Inject the Action Mapper
*
* @param actionMapper The Action Mapper
*/
@Inject
public void setActionMapper (ActionMapper actionMapper) {
this.actionMapper = actionMapper;
log.debug("Struts Action Mapper {}",actionMapper);
} //setActionMapper
But the attributes never get injected into the class. Is there
something else that I have to configure to get this working? Thanks.
(*Chris*)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] The death of the .action extension
Thanks Ted. The assumption is still that the action names are in the same package, so I added a new feature request for an annotation that combines the action and namespace. I find this particularly useful when a single action class can be used from several workflows, yet the URL (action/namespace) needs to remain consistent for the current workflow. I think it also matches the view tags better (url,form) as they always provide an action name and namespace attribute. /Ian Ted Husted wrote: Yes, SmartURLs does provide annotations for responding to multiple Action names. * http://code.google.com/p/smarturls-s2/wiki/CustomizationViaAnnotations On 9/10/07, Ian Roughley <[EMAIL PROTECTED]> wrote: The one issue that I haven't found a good solution for (and my apologies if it exists in the smartURLs package - it's on my list of things to look at) is when an action class needs to be mapped to multiple URL actions potentially different packages. This is one time that I find myself falling back to XML configuration, when I would prefer to use annotations. Is anyone working on anything like this? /Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] The death of the .action extension
The one issue that I haven't found a good solution for (and my apologies if it exists in the smartURLs package - it's on my list of things to look at) is when an action class needs to be mapped to multiple URL actions potentially different packages. This is one time that I find myself falling back to XML configuration, when I would prefer to use annotations. Is anyone working on anything like this? /Ian PS - and thanks Don, now I have to scrub a good part of a chapter on ActionMappers ;-) James Holmes wrote: +1 Ted, I'm with you 100%. James Mitchell and Bill Siggelkow have been preaching to me about Rails for 6 months now and I have finally taken the time to dig in deeper. And they are right! It has some amazing concepts. I can't wait to see how we can evolve Struts towards achieving some of the excellent concepts implemented in Rails. james On Mon Sep 10 9:55 , 'Ted Husted' <[EMAIL PROTECTED]> sent: I'm on board with Don's direction, and I'd like to try doing a ReSTful, Zero-Configuration, Code Behind MailReader this week, based on Brian's SmartURLs plugin, which is putting it all together in a single package. I believe the key point is that we have to develop architectures and coding paradigms that let us "say it once". A very good way to say it once is to say it with naming conventions, and to say it the URI. (And when that doesn't work, annotations!) Many of us are already use conventions and packed URIs, we just haven't been telling the *framework* enough about our conventions so that it could follow along on its own. Personally, I don't see this as a move away from the WebWork or Struts coding styles, but a natural progression. (Code-behind is wildcards without the wildcards.) We've been trying to write applications this way all along. We just couldn't see the architectural forest through the XML-strewn trees. :) -Ted. On 9/8/07, Don Brown [EMAIL PROTECTED]> wrote: Personally, I think we have a lot to learn from rails as they play very well off the strengths of the action-based Model2 architecture. Action-based frameworks strengths: * Simple workflow as in URL -> Action -> View * Intuitive (using conventions) URL -> Action mappings * RESTful by being close the the HTTP protocol * Scalable by not storing view state on the server * Lightweight in terms of code size and concepts needed to master As our goal is to make developing scalable applications easier and quicker, I think we have a lot to learn from rails. I hope to spend some time beefing up the RESTful aspects of Struts 2 both for web services and for regular HTML-based applications. You are right in that there are a lot of options in Struts 2, and we need to do a better job of providing a simple front to Struts 2 that doesn't bombard you with all its options and features. As the web moves to embrace more and more Ajax and web service functionality, I think Struts 2 and its action-based architecture will be well-suited to meet those needs. If you want to drop components on a page, obviously Struts 2 isn't for you, but if you want a framework on which to build a scalable, public-facing web application supporting mobile, web service, and Ajax clients, I hope Struts 2 will be the logical choise. Don On 9/9/07, Tom Schneider [EMAIL PROTECTED]> wrote: Don Brown wrote: Right, and that's why I didn't move to kill it off for 2.1. Give it some time, let the feature get some exercise, then if all agree, we could change the default later. As with any new feature, I'd put it in a sort of experimental category for at least one major release. So, do you have a final goal in mind for this or are you just working to open up options? I'd be very interested in hearing of the any options we have. Are we moving more towards Rails, or are there other better alternatives? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hold 2.0.10
Sounds good to me. Ted Husted wrote: So, if everyone is good to go on Struts 2.0.10, I could roll it Sunday night (9 Sep). -Ted. http://husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hold 2.0.10
Added. I assigned it to Musachy (I hope you don't mind), as I haven't looked at the tag code for over 6 months now and hopefully he can do the upgrade faster than I can. I am also under some tight deadlines for a new book (which is how I found the problem), but could look into fixing it the week after next if still open. /Ian Ted Husted wrote: On 8/23/07, Ian Roughley <[EMAIL PROTECTED]> wrote: If this is the case, then I'll submit this issue and I think we should include it in the 2.0.10 release. Sure. Put the issue in as a showstopper, and then make the change as quickly as you can. Good catch, Ian. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Hold 2.0.10
Guys - In the thread "Re: Dojo 0.9 final. Time to migrate in S2?" I noticed that Musachy mentioned that the s2.1.x tags were dojo 0.4.2. Is this the case for the 2.0.x branch as well? If it is, I was doing some research, and came across the following:* "Dojo* 0.4.3 is now available to download. This is a security release. *Dojo* 0.4.1 and 0.4.2 users are strongly recommended to upgrade as soon as possible. 0.4.1 and 0.4.2 have a flaw in two files that could allow cross site scripting (*XSS*) attacks against your site if you do not upgrade." If this is the case, then I'll submit this issue and I think we should include it in the 2.0.10 release. /Ian
Re: [S2] [2.1.x] Bundled Plugins
Ted Husted wrote: I'm not sure that anyone is maintaining them now. I'm not sure that they all work. My thinking is that if they are kept at another location where there is a lower bar to entry, then perhaps we can attract someone to maintain them. Or, the other option is that no one picks them up and then they are outdated to the changes in the s2 code base. My concern is that some of the code in our distribution is not being used, or otherwise fully tested, by anyone in the group. When that is the case, then we should not be distributing the code. This is my biggest concern. When I look at rails the biggest thing I see is that every aspect of the core code works well, is integrated and documented (or maybe I'm just lucky and this is all I've come across so far). There is also a thriving plugin community, which is independent from the core. Perhaps what is needed is a more understood labeling mechanism. So far we have "experimental", but there are experimental features that are documented and in excellent shape - so much so that I am using them in production code. And there is other non-labeled code that I am very cautious of using (XSLT results). For the plugins kept in s2, the other change I would like to see is independent life cycles. If the code has not changed, I'm not sure why its version needs to be incremented (other than staying with the s2 core version). Would independent SVN repos help here? In retrospect, perhaps keeping the dojo plugin in s2 is the way to go (the discussion that started this), but I still believe that an independent life cycle is needed (someone just asked whether 2.0.x was going to upgrade dojo from 0.4 to 0.9). We should archive it, and, perhaps, for added value, make it available at another location. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ajax Theme
My personal preference would be out of Struts - unless, the plugins within Struts2 can have independent life cycles (which at the moment doesn't seem to be the case). And, once again, this is biased on the implementation of the ww2 tags where the dojo API was rapidly changing :) If the dojo API has settled to a point where s2 can be one or two point release behind the most recent, or user can easily swap out the s2 dojo scripts for the most recent dojo scripts and have the plugin functionality work, I would be okay with the dojo plugin staying in the struts2 core as a plugin. Musachy, - what is the percentage of code that has changed between 2.0.x and 2.1.x as far as the Ajax tags implementation goes? /Ian Musachy Barroso wrote: do you mean to move the plugin out of Struts? Because Dojo is already on its own plugin in trunk. musachy On 8/18/07, James Holmes <[EMAIL PROTECTED]> wrote: +1 on moving Dojo out of the core to a plugin. -Original Message----- From: Ian Roughley [mailto:[EMAIL PROTECTED] Sent: Saturday, August 18, 2007 1:34 PM To: Struts Developers List Subject: Re: Ajax Theme So let me ask this - what is the percentage of code that has changed between 2.0.x and 2.1.x as far as the Ajax tags go? To answer Ted's questions, my feeling to is move them out the core and into a plugin. There have been quiet a few headaches with dojo upgrades during the initial ww2 implementation. If nothing else, it would allow the dojo and s2 release schedules to proceed independently (i.e. s2 users would not be forced to use an old version of dojo until the new s2 release, because of a dojo API change). /Ian Musachy Barroso wrote: On 2.1 ajax validation will be provided by Dojo by default, but other libraries can be used easily, (with prototype example): http://struts.apache.org/2.x/docs/ajax-validation.html musachy On 8/17/07, Ted Husted <[EMAIL PROTECTED]> wrote: I haven't dived into this part of the source code, but I've beent taking "The ajax validation depends on DWR" to mean that we use DWR to call the usual server-side validators from client-side ajax code. Is that correct? Is the use of DWR changing from 2.0.x to 2.1.x? Does the YUI Ajax plugin support validation? Has anyone tried the YUI plugin against the head? (And just to make our question day complete:) Do we want to bundle the Dojo plugin with Struts 2.1.x, or do we want to consider moving it to a Google Code site (perhpas with YUI), while it is still "experimental": -Ted. On 8/15/07, Musachy Barroso <[EMAIL PROTECTED]> wrote: The ajax validation depends on DWR musachy On 8/15/07, Ian Roughley <[EMAIL PROTECTED]> wrote: Is the ajax theme in the 2.0.x branch completely Dojo driven now? If so, there seems to be a lot of DWR code that could be removed (i.e. from the web.xml and form.ftl). I can open a ticket if this is the case. /Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "Hey you! Would you help me to carry the stone?" Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted <http://www.husted.com/ted/blog/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ajax Theme
So let me ask this - what is the percentage of code that has changed between 2.0.x and 2.1.x as far as the Ajax tags go? To answer Ted's questions, my feeling to is move them out the core and into a plugin. There have been quiet a few headaches with dojo upgrades during the initial ww2 implementation. If nothing else, it would allow the dojo and s2 release schedules to proceed independently (i.e. s2 users would not be forced to use an old version of dojo until the new s2 release, because of a dojo API change). /Ian Musachy Barroso wrote: On 2.1 ajax validation will be provided by Dojo by default, but other libraries can be used easily, (with prototype example): http://struts.apache.org/2.x/docs/ajax-validation.html musachy On 8/17/07, Ted Husted <[EMAIL PROTECTED]> wrote: I haven't dived into this part of the source code, but I've beent taking "The ajax validation depends on DWR" to mean that we use DWR to call the usual server-side validators from client-side ajax code. Is that correct? Is the use of DWR changing from 2.0.x to 2.1.x? Does the YUI Ajax plugin support validation? Has anyone tried the YUI plugin against the head? (And just to make our question day complete:) Do we want to bundle the Dojo plugin with Struts 2.1.x, or do we want to consider moving it to a Google Code site (perhpas with YUI), while it is still "experimental": -Ted. On 8/15/07, Musachy Barroso <[EMAIL PROTECTED]> wrote: The ajax validation depends on DWR musachy On 8/15/07, Ian Roughley <[EMAIL PROTECTED]> wrote: Is the ajax theme in the 2.0.x branch completely Dojo driven now? If so, there seems to be a lot of DWR code that could be removed (i.e. from the web.xml and form.ftl). I can open a ticket if this is the case. /Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "Hey you! Would you help me to carry the stone?" Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted <http://www.husted.com/ted/blog/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Custom URL in Struts 2
The Restful2ActionMapper will call different methods of the action class depending on the HTTP type. If this is not important, or you are using different actions then the UrlRewriteFilter is a great option. The Restful2ActionMapper is also part of Struts2 ;-) /Ian mraible wrote: What's the advantage of using Restful2ActionMapper/CompositeActionMapper over something like the UrlRewriteFilter? http://tuckey.org/urlrewrite/ I like the UrlRewriteFilter because it can alter outgoing URLs to be RESTful-looking as well. Matt Ian Roughley wrote: Writing a custom ActionMapper is the way to go - it maps the URL to an action configuration and back again. I would write one for the "http://mysearchsite.com/XYZ+ABC"; pattern, and then use the Restful2ActionMapper for the "http://myseachsite.com/images/1"; pattern. The CompositeActionMapper will allow you to combine both these together in your application. /Ian Brian Pontarelli wrote: This is very rails like. This is a tough one because of the way that Struts handles the URL to find the action mapping. If you want to support the Rails ID concept inside your URLs, I would suggest writing a custom filter to change the URL as it comes in based on some pre-defined criteria. You could also try implementing a different action mapper (although I've never done that, so I'm not certain how difficult it would be). You might also be able to leverage wild-card mappings to get what you need. -bp rakeshxp wrote: Hello Everyone, I am trying to figure out on how to implement custom URL format in Struts 2. Specifically, I needed URLs like -> http://mysearchsite.com/XYZ+ABC => This should be calling a default Action class and pass XYZ , ABC as parameters -> http://myseachsite.com/images/1 => This should be calling an Image Action class with 1 as a parameter Has anyone achieved the above mentioned requirements before or can help me do so ? thanks in advance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ajax Theme
Is the ajax theme in the 2.0.x branch completely Dojo driven now? If so, there seems to be a lot of DWR code that could be removed (i.e. from the web.xml and form.ftl). I can open a ticket if this is the case. /Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Custom URL in Struts 2
Writing a custom ActionMapper is the way to go - it maps the URL to an action configuration and back again. I would write one for the "http://mysearchsite.com/XYZ+ABC"; pattern, and then use the Restful2ActionMapper for the "http://myseachsite.com/images/1"; pattern. The CompositeActionMapper will allow you to combine both these together in your application. /Ian Brian Pontarelli wrote: This is very rails like. This is a tough one because of the way that Struts handles the URL to find the action mapping. If you want to support the Rails ID concept inside your URLs, I would suggest writing a custom filter to change the URL as it comes in based on some pre-defined criteria. You could also try implementing a different action mapper (although I've never done that, so I'm not certain how difficult it would be). You might also be able to leverage wild-card mappings to get what you need. -bp rakeshxp wrote: Hello Everyone, I am trying to figure out on how to implement custom URL format in Struts 2. Specifically, I needed URLs like -> http://mysearchsite.com/XYZ+ABC => This should be calling a default Action class and pass XYZ , ABC as parameters -> http://myseachsite.com/images/1 => This should be calling an Image Action class with 1 as a parameter Has anyone achieved the above mentioned requirements before or can help me do so ? thanks in advance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache Roller 4.0 (rc1): new, improved and powered by Struts 2
Is this the version that IBM is bundling in their products, or was it an older version? /Ian PS - Great meeting you at J1 Dave wrote: On 8/13/07, Philip Luppens <[EMAIL PROTECTED]> wrote: Very interesting - did you already have the chance to test the performance in the wild ? Yes. The 4.0 code-base has been running on blogs.sun.com for about a month now. - Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Preventing OGNL evaluations of user input (was Re: Struts 2 performance)
What do you define as "a user should not be allowed to execute such OGNL
code!"? There are times that I want to call a static method and use the
results. The problem to me (and as Don pointed out), is that there is
malicious code stored in the database that was entered by users - and is
a type of XSS attack.
The other option is that a hacker as access to your web app file system
and is changing a template. If this is the case, my personal feeling is
that you should be glad they are only changing templates and not doing a
number of other things :-)
/Ian
Antonio Petrelli wrote:
2007/7/16, Ing. Andrea Vettori <[EMAIL PROTECTED]>:
What about expression like "%{foo} %{bar}" that work with the current
version but don't work using the loopCounter patch ?
I don't think we need them but who knows...
I think that recursion is a false problem: it's up to the developer to
control it (I don't think that JSP EL controls it, correct me if I am
wrong). Eventually a log message can be written, but preventing it is
not a
solution, because a particular case (such as circular reference) will be
always present.
The "real" problem is that a user should not be allowed to execute
such OGNL
code!
Antonio
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: RIA + Struts
Struts2 can return XML or JSON (via a plug-in). What are the RIAs you are reviewing, and what integration options do they provide to obtain back-end data? /Ian Gerardo Corro wrote: Hi, I need to create a really fancy GUI, so I've been thinking about integrating struts with a Rich Internet Application framework (RIA) Is there a recomendation about which RIA is a good option to be used in conjuction with Struts? Or Is there a good view layer technology that is recomended to be used with struts? Thanks a lot! - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=100326&messageID=168913#168913 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Struts Annotations 1.0.2
+0 for GA. I have to admit I didn't realize that annotations were a different project, but have been using them in 2.0.8 without issue. /Ian Rainer Hermanns wrote: Struts Annotations 1.0.2 has been tagged and is available for testing in the following Maven repository: http://people.apache.org/builds/struts/struts-annotations-1.0.2/m2-staging-repository/ To test this build, temporarily add a repository to pom.xml or settings.xml. The the struts-annotations dependency version number in the Struts2 on branch STRUTS_2_0_X has already been altered to "1.0.2". struts-annotations-102-staging Struts Annotations 1.0.2 Staging Repository http://people.apache.org/builds/struts/struts-annotations-1.0.2/m2-staging-repository/ This is a build-time dependency for Struts 2, and there is no distribution assembly, though source and javadoc jars are available in the Maven repo. Once you have had a chance to test this build, please vote on whether to release it to the central Maven repository. -Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] [VOTE] Struts 2.0.8 Quality
[X] General Availability (GA) Rainer Hermanns wrote: The Struts 2.0.8 test build is now available. Release notes: * http://cwiki.apache.org/confluence/display/WW/Release+Notes+2.0.8 Distribution: * http://people.apache.org/builds/struts/2.0.8/ Maven 2 staging repository: * http://people.apache.org/builds/struts/2.0.8/m2-staging-repository/ Once you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and more +1s than -1s. The vote will remain open for at least 72 hours, longer upon request. A vote can be amended at any time to upgrade or downgrade the quality of the release based on future experience. If an initial vote designates the build as "Beta", the release will be submitted for mirroring and announced to the user list. Once released as a public beta, subsequent quality votes on a build may be held on the user list. As always, the act of voting carries certain obligations. A binding vote not only states an opinion, but means that the voter is agreeing to help do the work -Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Proposal for new url processing
Is it the UnknownHandler that is used by the code behind plugin?
/Ian
Don Brown wrote:
In Struts 2.1 (and XWork 2.1), I'm thinking about reworking how we
process
urls and convert them to actions. Specifically, I want to make it
possible
for the Struts 2 dispatcher filter to potentially examine every
request, and
if no action is found, pass control down the filter chain. The goal
of this
improvement would be so that Struts 2 could intercept /* but not look for
any particular file extension. This would allow a Struts 2 app to be
able
to use the .html extension, but still support static html files.
The primary use case I have in mind is a friendly restful
application. This
app has urls like:
http://example.com/book/War+and+Peace
Only you want to serve up different views of the action simultaneously:
http://example.com/book/War+and+Peace.xml
http://example.com/book/War+and+Peace.html
http://example.com/book/War+and+Peace.json
The most natural way to do this is to use the extension. However, if you
have Struts 2 handle all requests, currently, you can't then have it
serve
any static files (Dojo, css, etc) and you can't use your web application
server to serve static files either (html, css, js, etc).
The workflow I envision goes like this:
1. Filter matches all URLs (/*)
2. ActionMapper determines the action name and namespace, if either a) an
extension is defined or b) all extensions are configured to be processed
3. The _dispatcher_ tries to find an ActionConfig from the Configuration
(currently this happens in the ActionProxy)
4. If an ActionConfig can be found (even trying the UnknownHandler), the
request is processed as usual by Struts 2 as an action
5. Otherwise, the filter sees if it is an internal Struts 2 resource to
return and does so
6. Otherwise, the filter lets the request go down the chain
To match the example urls above, you would configure Struts 2 to not
use an
action extension. Then, in your action, you could match urls that
include
the extension:
{1}
viewBook.jsp
From here, we could later do interesting things like:
{1}
viewBook-html.jsp
Using a dynamic proxy for the Action that manipulated the returned result
based on the url extension. I'm getting ahead of myself, but you get the
idea of where I'm going with this.
Thoughts?
Don
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Where's Waldo?
Yeah... one book at the publisher (out in a couple of weeks), and the time I estimated for the second one was ridiculously low :) So now I am spending every free minute and reducing my consulting workload to meet deadlines. /Ian Philip Luppens wrote: Hmm, same here. Too busy with the new job. I'm still working on various S2 plugins at nighttime. As for the rest of the old WW team I know about: - Rainer: too much work for clients atm - Rene: on vacation - Ian: writing book(s) - Toby: focused on bugfixes for WW atm (has some legacy apps to take care of) Personally, I'd like to know what Nils is doing (he is/was working on the portlet plugin, but waiting for the URLBuilder), and where Tom is atm (haven't heard from him in a long time). I suppose everyone is just a tad too busy or on vacation .. Cheers, Phil On 5/18/07, James Mitchell <[EMAIL PROTECTED]> wrote: Again, sorry, we are still trying to close out phase 2 on my day job (JSF/EJB/Hibernate), before we can start on phase 3 (Struts 2/Spring/ JPA -- dumping JSF and EJB). Also, I picked up another small side job (RoR) so that is eating up more of my spare time. Shouldn't be too much longer before I can turn more attention back to s2. -- James Mitchell On May 17, 2007, at 3:31 PM, Musachy Barroso wrote: > I'm going to start cleaning up open issues and apply patches for > 2.0.8, when > I'm done wit the remaining Dojo issues on 2.1 (couple of them), I > think > Antonio and James both volunteered to make the builds, any news on > that? > > regards > musachy > > On 5/17/07, Ted Husted <[EMAIL PROTECTED]> wrote: >> >> I'll be very heads-down for the next six weeks, and after that, I'll >> be working on something else entirely over the summer. >> >> Will anyone else be available this summer to help apply patches and >> march us toward releases of Struts 2.0.8 and Struts 2.1.0? >> >> Musachy has been doing a lot of work on the Dojo plugin, but there a >> number of other outstanding patches, and we should ask ourselves >> whether we still have volunteers with the time to at least make >> routine changes. >> >> -Ted. >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > -- > "Hey you! Would you help me to carry the stone?" Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ApacheCon
I would be up for a collaboration, if there are others that are interested. /Ian Mark Menard wrote: On 4/23/07 1:03 PM, "Dave Newton" <[EMAIL PROTECTED]> wrote: --- Ian Roughley <[EMAIL PROTECTED]> wrote: Is anyone considering submitting a speaking proposal on s2 for ApacheCon this year? I was going to, but I couldn't think of a good topic, and Mark already took the only one I had thought of :) Hey, is that a back handed compliment? ;) I'm open to suggestions, though. How about a full or half day training session? I'd be willing to help with one, but I don't really feel up to presenting it completely on my own. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ApacheCon
Is anyone considering submitting a speaking proposal on s2 for ApacheCon this year? /Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PROPOSAL: S2 ajax validation
Is the Ajax code all in a module now (2.1.x)? Would this change be checked into the 2.0.x branch or just the trunk under the Ajax module, and then some cleanup/removal of existing code in the trunk? /Ian Musachy Barroso wrote: I have this working, but I want to give it a little more time to anyone to object before committing it :), just to review, these are the different validation options: 1. regular form, regular submit button (normal validation) 2. css_html form, or xhtml form (validate="true"), regular submit button (client validation) 3. css_html form, or xhtml form (validate="true"), ajax submit button (client validation) 4. regular form, css_html form, or xhtml form, where action has the "ajaxValidation" interceptor, ajax submit button (validate="true") (ajax validation = dojo+interceptor, no DWR) regards musachy On 4/21/07, Musachy Barroso <[EMAIL PROTECTED]> wrote: I'd like to propose a change on the way we do ajax validation. Instead of using DWR which requires an external dependency and configuring a servlet, I'd like to have an interceptor in the dojo plugin that extends the validator interceptor, which outputs JSON with the messages when there are validation errors. To use ajax validation all a user would have to do is add the interceptor to his/her class and set "validate" to "true" in either the form, or the submit/anchor that is submitting the form. regards musachy -- "Hey you! Would you help me to carry the stone?" Pink Floyd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
converter field in action configuration
Does anyone know why there is a "converter" field in the DTD for an action? I checked the XmlConfigurationProvider and it isn't using the fields data. Was this a hold-over from somewhere, or a new feature that isn't quiet there yet? Thanks, Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Struts 2.0 MVC Award
Also, in honour of Don and our friends at Atlassian, I'd like to designate a new official beer for Struts 2 -- you guessed it -- Fosters! Only an American would suggest Fosters ;-) Let's go for VB or Tooheys since he'll end up in NSW. You can bet that I'll be tipping myself a big blue can tonight! -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: archetype
Wendy Smoak wrote: Is there a reason that Spring 1.2.8 is declared in the pom generated from the archetype, instead of letting the struts2-spring-plugin determine the version? I was wondering about that myself. /Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.5 Quality
+0 for GA. I have some testing code that looks good, but no production code that has been converted. /Ian Ted Husted wrote: The Struts 2.0.5 test build is now available. Release notes: * http://struts.apache.org/2.x/docs/release-notes-205.html Distribution: * http://people.apache.org/builds/struts/2.0.5/ Maven 2 staging repository: * http://people.apache.org/builds/struts/2.0.5/m2-staging-repository/ If you have had a chance to review the test build, please respond with a vote on its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and more +1s than -1s. Please remember that a *binding* +1 for GA implies that you intend to support the release by applying patches and responding to posts to the user and dev lists. The vote will remain open for at least 72 hours, longer upon request. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed change to archetype
Ok Ted, I'll only modify the starter application. However, looking through the validation and localization sections of the bootstap tutorial, I didn't see any explicit reference to needing to move the files from the com/myComp/myApp directory into the mirrored class directory, if you used the maven archetype. This may lead to confusion, as the new user sees documentation saying one thing and the archetype result showing another. It made me think twice, and I am familiar with the framework. It also brings up the question of "are we advocating property files for validation and conversion?" Thinking about it more, my plan was to replace the removed files with valid annotations. As a group are we pushing forward in the direction to keep, but not promote xml/property file configuration and move toward annotations and default configurations - or to keep and promote both? /Ian Ted Husted wrote: The blank application contains the files from the bootstrap tutorial. * http://struts.apache.org/2.x/docs/bootstrap.html The tutorial files are put "out of the way" so that people don't need to delete them just to get started. But, they are still there for reference. So, no, don't make the same changes, and, later, I'd like to change the achetype back. On 1/31/07, Ian Roughley <[EMAIL PROTECTED]> wrote: I was going to run with this. Did you want me to make the same deletions to the blank application? After all, since they are not in the correct directory, the files are not being used. /Ian Ted Husted wrote: > Once things are sorted out, it would be nice to revert it to match the > Struts Blank application, but for now, it seems like we should strip > it down. > > On 1/30/07, Ian Roughley <[EMAIL PROTECTED]> wrote: >> I have been looking through the s2 maven archetypes, and would like to >> propose that we don't include resources that are at a package level >> (i.e. validation and conversion). The reason being that maven2 >> currently does not support this feature (see >> http://jira.codehaus.org/browse/ARCHETYPE-54), so for a groupId of >> "com.test" the directory structure becomes: >> >> /src/main/java/com/test/HelloWorldAction >> /src/main/resources/som/myComp/myApp/HelloWorldAction-validation.xml >> /src/main/resources/som/myComp/myApp/IndexAction.properties >> /src/main/resources/som/myComp/myApp/IndexAction-conversion.properties >> >> I think having the resources in the wrong directory is more confusing >> that not having them. Once ARCHETYPE-54 is implemented we can go add >> them back in. >> >> What does everyone think? >> >> /Ian > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed change to archetype
I was going to run with this. Did you want me to make the same deletions to the blank application? After all, since they are not in the correct directory, the files are not being used. /Ian Ted Husted wrote: Once things are sorted out, it would be nice to revert it to match the Struts Blank application, but for now, it seems like we should strip it down. On 1/30/07, Ian Roughley <[EMAIL PROTECTED]> wrote: I have been looking through the s2 maven archetypes, and would like to propose that we don't include resources that are at a package level (i.e. validation and conversion). The reason being that maven2 currently does not support this feature (see http://jira.codehaus.org/browse/ARCHETYPE-54), so for a groupId of "com.test" the directory structure becomes: /src/main/java/com/test/HelloWorldAction /src/main/resources/som/myComp/myApp/HelloWorldAction-validation.xml /src/main/resources/som/myComp/myApp/IndexAction.properties /src/main/resources/som/myComp/myApp/IndexAction-conversion.properties I think having the resources in the wrong directory is more confusing that not having them. Once ARCHETYPE-54 is implemented we can go add them back in. What does everyone think? /Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Proposed change to archetype
I have been looking through the s2 maven archetypes, and would like to propose that we don't include resources that are at a package level (i.e. validation and conversion). The reason being that maven2 currently does not support this feature (see http://jira.codehaus.org/browse/ARCHETYPE-54), so for a groupId of "com.test" the directory structure becomes: /src/main/java/com/test/HelloWorldAction /src/main/resources/som/myComp/myApp/HelloWorldAction-validation.xml /src/main/resources/som/myComp/myApp/IndexAction.properties /src/main/resources/som/myComp/myApp/IndexAction-conversion.properties I think having the resources in the wrong directory is more confusing that not having them. Once ARCHETYPE-54 is implemented we can go add them back in. What does everyone think? /Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts2 and Java 1.4 (Re: [VOTE] Struts 2.0.4 Quality)
Does this infer that the only jar being voted on is the struts2-core.jar? And if so, does this make sense - especially given that all the DI options are in plugins. /Ian Ted Husted wrote: As it stands, we are marking a number of features and plugins "experimental", because they have not had wide enough testing. The 1.4 support should be labeled experimental too, since I don't think many people have been trying it. The J4 stuff is also a separate set of JARs, and we decided that the GA votes could go by JAR, so that some plugins could be rated GA will others would be left at beta. -Ted. On 1/30/07, Joe Germuska <[EMAIL PROTECTED]> wrote: Struts 2 is written for Java 5. The Java 1.4 compatible jars are a convenience for some users, but I do not think they should be considered fully supported or a blocking issue for a Struts 2 release. Anyone strongly disagree? Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.4 Quality
+1 beta Ted Husted wrote: Since the Struts 2.0.4 build is essentially the 2.0.3 build with Maven fixes, I thought we might as well start the vote. If after three days anyone needs more time, or we don't have a quorum, then we can just leave the vote open for as long as it takes. Release notes: * http://struts.apache.org/2.x/docs/release-notes-204.html * http://struts.apache.org/2.x/docs/release-notes-203.html Distribution: * http://people.apache.org/builds/struts/2.0.4/ Maven 2 staging repository: * http://people.apache.org/builds/struts/2.0.4/m2-staging-repository/ Once you have had a chance to review the test build, please respond with a vote as to its quality: [ ] Leave at test build [ ] Alpha [ ] Beta [ ] General Availability (GA) Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and more +1s than -1s. Please remember that a binding +1 for GA implies that you intend to support the release by applying patches and responding to posts to the user and dev lists. Unless we decide otherwise, a beta vote implies that we will announce the build to the user list, to encourage wider testing. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Tag reorganization
Yeah, but given the problems that most people have at some stage of debugging with the tags, I thought there would be more traffic ;-) /Ian Mitchell James wrote: That's the wonderful or terrible thing about successful OSS projects, you are kidding yourself if you think even 5% of the users are even on a mailing list, much less that they will read every post. -- James Mitchell 678.910.8017 On Dec 29, 2006, at 8:09 AM, Ian Roughley wrote: If we go the from route, then it should be a simple global find and replace. I am surprised at such a large use of the tags though. I've asked more than a couple of times if anyone was using them, and there was never a response. /Ian Shekhar Yadav wrote: We are using 2.0.1 and we are using form/div with ajax based theme. Is it going to be major problem for us to migrate to new tags. If so what are you recommendations, we are in process of building and only half way through. I don't want to create 250 screens with tags that are going to be outdated by the time we release the app. - Shekhar -Original Message- From: Ian Roughley [mailto:[EMAIL PROTECTED] Sent: Thursday, December 28, 2006 7:36 AM To: Struts Developers List Subject: Re: [proposal] Tag reorganization I'm torn - I like the fact that we are getting the ajax code out of the base, but especially for webwork->s2 upgrades there is going to be more work. The other thing is that 2.0.2 is still beta, and frankly I don't think there is that many people using the tags at the moment, so this would be a good time to make the change. /Ian David H. DeWolf wrote: That's what I'm imagining too. . .and we're agreeing that this incompatibility is a pill we have to swallow. Ian Roughley wrote: I think I am missing something here - how will the tags be invoked? It will need to be a new tld with a new name space, right? Something like rather than - so there will be a compatibility issue, but all the functionality will be moved forward. /Ian David H. DeWolf wrote: Ted Husted wrote: Don mentioned a separate tag library, so that would indicate another prefix, but there'd be no reason why the internal tag syntax would change. To keep the codebase manageable, I believe we do need to make this change, and I'd rather make it now while we are in our first beta series than after the first Struts 2 GA. The plugin model might also open the door to other AJAX implementations of the same tags. I agree. I like it, but just wanted to make sure we think through the compatibility changes before we make a decision. In essence we're saying that this change is more important than backwards compat of this one tag and we're willing to live with those repercussions. I'm on board with that. -T. On 12/27/06, David H. DeWolf <[EMAIL PROTECTED]> wrote: Ok, as long as we keep the tag prefixes and tag names once they are abstracted from the plugin. At one point we talked about having a simple version which is extended by the dojo version and added additional (dojo-specific) featuers. It seems like the current names would be more likely be used for the core tags - not the dojo-enhanced ones. Ted Husted wrote: A struts-dojo plugin shouldn't change the tag syntax. It should just be a matter of adding the JAR, as we do for Spring, and JasperReports, and Tiles, so forth. On 12/27/06, David H. DeWolf <[EMAIL PROTECTED]> wrote: Nope, that's the one I'm talking about. I got the impression we were going to keep it as is and thus break backwards compatibility in 2.0.2 -- and then mess with it again it when we create the plugin. . . David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Struts 2.0.2 status
Don Brown wrote: The change I made to xwork is a very minor, internal Guice improvement that should have no impact on its GA release. I haven't checked with Rainer lately, but I'd imagine XWork 2.0 could go final very soon. I spoke with him at Javapolis, and I believe everything was ready to go. As for branching for 2.1, yeah, we could do that. I was thinking of doing the ajax tag changes now, since tag changes for future versions are generally very painful for people, and honestly, I just don't feel comfortable with the tags now. For example, as a placeholder during the incubation, I changed the simple theme to always import Dojo, which is clearly not a good idea. I'd really like to clean Dojo out of core, so we can keep the core tags as simple as possible. Simple generally equals easier to stabilize. Still, if that isn't the consensus, I can do the changes in the branch. I *really* like the idea to externalize the ajax tags (although I haven't had the time personally to help out with this). What did you end up doing with the DWR validation for forms? I'm very much interested in a GA release in Jan or Feb, but I do want to make sure it isn't one we are ashamed of. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Tag reorganization
If we go the from route, then it should be a simple global find and replace. I am surprised at such a large use of the tags though. I've asked more than a couple of times if anyone was using them, and there was never a response. /Ian Shekhar Yadav wrote: We are using 2.0.1 and we are using form/div with ajax based theme. Is it going to be major problem for us to migrate to new tags. If so what are you recommendations, we are in process of building and only half way through. I don't want to create 250 screens with tags that are going to be outdated by the time we release the app. - Shekhar -Original Message----- From: Ian Roughley [mailto:[EMAIL PROTECTED] Sent: Thursday, December 28, 2006 7:36 AM To: Struts Developers List Subject: Re: [proposal] Tag reorganization I'm torn - I like the fact that we are getting the ajax code out of the base, but especially for webwork->s2 upgrades there is going to be more work. The other thing is that 2.0.2 is still beta, and frankly I don't think there is that many people using the tags at the moment, so this would be a good time to make the change. /Ian David H. DeWolf wrote: That's what I'm imagining too. . .and we're agreeing that this incompatibility is a pill we have to swallow. Ian Roughley wrote: I think I am missing something here - how will the tags be invoked? It will need to be a new tld with a new name space, right? Something like rather than - so there will be a compatibility issue, but all the functionality will be moved forward. /Ian David H. DeWolf wrote: Ted Husted wrote: Don mentioned a separate tag library, so that would indicate another prefix, but there'd be no reason why the internal tag syntax would change. To keep the codebase manageable, I believe we do need to make this change, and I'd rather make it now while we are in our first beta series than after the first Struts 2 GA. The plugin model might also open the door to other AJAX implementations of the same tags. I agree. I like it, but just wanted to make sure we think through the compatibility changes before we make a decision. In essence we're saying that this change is more important than backwards compat of this one tag and we're willing to live with those repercussions. I'm on board with that. -T. On 12/27/06, David H. DeWolf <[EMAIL PROTECTED]> wrote: Ok, as long as we keep the tag prefixes and tag names once they are abstracted from the plugin. At one point we talked about having a simple version which is extended by the dojo version and added additional (dojo-specific) featuers. It seems like the current names would be more likely be used for the core tags - not the dojo-enhanced ones. Ted Husted wrote: A struts-dojo plugin shouldn't change the tag syntax. It should just be a matter of adding the JAR, as we do for Spring, and JasperReports, and Tiles, so forth. On 12/27/06, David H. DeWolf <[EMAIL PROTECTED]> wrote: Nope, that's the one I'm talking about. I got the impression we were going to keep it as is and thus break backwards compatibility in 2.0.2 -- and then mess with it again it when we create the plugin. . . David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Tag reorganization
I'm torn - I like the fact that we are getting the ajax code out of the base, but especially for webwork->s2 upgrades there is going to be more work. The other thing is that 2.0.2 is still beta, and frankly I don't think there is that many people using the tags at the moment, so this would be a good time to make the change. /Ian David H. DeWolf wrote: That's what I'm imagining too. . .and we're agreeing that this incompatibility is a pill we have to swallow. Ian Roughley wrote: I think I am missing something here - how will the tags be invoked? It will need to be a new tld with a new name space, right? Something like rather than - so there will be a compatibility issue, but all the functionality will be moved forward. /Ian David H. DeWolf wrote: Ted Husted wrote: Don mentioned a separate tag library, so that would indicate another prefix, but there'd be no reason why the internal tag syntax would change. To keep the codebase manageable, I believe we do need to make this change, and I'd rather make it now while we are in our first beta series than after the first Struts 2 GA. The plugin model might also open the door to other AJAX implementations of the same tags. I agree. I like it, but just wanted to make sure we think through the compatibility changes before we make a decision. In essence we're saying that this change is more important than backwards compat of this one tag and we're willing to live with those repercussions. I'm on board with that. -T. On 12/27/06, David H. DeWolf <[EMAIL PROTECTED]> wrote: Ok, as long as we keep the tag prefixes and tag names once they are abstracted from the plugin. At one point we talked about having a simple version which is extended by the dojo version and added additional (dojo-specific) featuers. It seems like the current names would be more likely be used for the core tags - not the dojo-enhanced ones. Ted Husted wrote: > A struts-dojo plugin shouldn't change the tag syntax. It should just > be a matter of adding the JAR, as we do for Spring, and JasperReports, > and Tiles, so forth. > > On 12/27/06, David H. DeWolf <[EMAIL PROTECTED]> wrote: >> Nope, that's the one I'm talking about. I got the impression we were >> going to keep it as is and thus break backwards compatibility in 2.0.2 >> -- and then mess with it again it when we create the plugin. . . >> >> David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Tag reorganization
I think I am missing something here - how will the tags be invoked? It will need to be a new tld with a new name space, right? Something like rather than - so there will be a compatibility issue, but all the functionality will be moved forward. /Ian David H. DeWolf wrote: Ted Husted wrote: Don mentioned a separate tag library, so that would indicate another prefix, but there'd be no reason why the internal tag syntax would change. To keep the codebase manageable, I believe we do need to make this change, and I'd rather make it now while we are in our first beta series than after the first Struts 2 GA. The plugin model might also open the door to other AJAX implementations of the same tags. I agree. I like it, but just wanted to make sure we think through the compatibility changes before we make a decision. In essence we're saying that this change is more important than backwards compat of this one tag and we're willing to live with those repercussions. I'm on board with that. -T. On 12/27/06, David H. DeWolf <[EMAIL PROTECTED]> wrote: Ok, as long as we keep the tag prefixes and tag names once they are abstracted from the plugin. At one point we talked about having a simple version which is extended by the dojo version and added additional (dojo-specific) featuers. It seems like the current names would be more likely be used for the core tags - not the dojo-enhanced ones. Ted Husted wrote: > A struts-dojo plugin shouldn't change the tag syntax. It should just > be a matter of adding the JAR, as we do for Spring, and JasperReports, > and Tiles, so forth. > > On 12/27/06, David H. DeWolf <[EMAIL PROTECTED]> wrote: >> Nope, that's the one I'm talking about. I got the impression we were >> going to keep it as is and thus break backwards compatibility in 2.0.2 >> -- and then mess with it again it when we create the plugin. . . >> >> David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ajaxtags] Date picker
Sorry - vacation. Cameron (no longer active) convinced us to go the dojo route and did all of the dojo widget coding. I did the webwork integration - and tried my hand at the dojo code after he became inactive. /Ian Ted Husted wrote: Are we just talking about the Ajax date/time picker? Ian, who did a lot of the original WW coding, seemed to think that the Ajax tags were not widely used yet. If we were going to break with the WW Ajax tags, this would be a good time. The key question is whether we can document the differences. -Ted. On 12/27/06, Musachy Barroso <[EMAIL PROTECTED]> wrote: The problem with the datepicker is worst than I thought, Dojo's DatePicker and TimePicker are way different that the ones that WW had. In order too keep it backward compatible, the best thing we can do is resurrect the "DatePicker.js" and "TimePicker.js" from WW, instead of using Dojo directly, like we do now. I will start to dig back and get the old files. musachy Ted Husted wrote: > OK, it's in r490569 > > Any feedback on WW-1573 - Handling of If-Modified-Since header for > static content > > Should we apply that too? > > -Ted. > > On 12/27/06, Musachy Barroso <[EMAIL PROTECTED]> wrote: >> When you apply the one for the autocompleter; I will create one for >> datepicker against head svn, and we'll just ignore the old one. >> >> regards >> musachy >> >> Ted Husted wrote: >> > I tried to apply the patch, but there were a great many conflicts, >> > perhaps because of other changes. I'm happy to apply as many patches >> > as we need to bring the Ajax theme up to speed, but I don't know dojo >> > well enough to resolve conflucts with overlapping changes. >> > >> > -Ted. >> > >> > On 12/27/06, Musachy Barroso <[EMAIL PROTECTED]> wrote: >> >> It seems like the patch for reverting the datepicker to its old >> name was >> >> never applied. (https://issues.apache.org/struts/browse/WW-1555) Does >> >> any one know what is the status of this one? >> >> >> >> regards >> >> musachy > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: We need to clean up the Struts 2 AJAX tags (was Re: Additional UI tags)
Just thought of a possible downside. Features that users may have expected as simple javascript / non-ajax, for example tool tip and calendar, are (I believe) now implemented using the dojo library. So there is not a clean separation between those tags that have communication and those that don't. /Ian Don Brown wrote: As much as I absolutely hate to say it, I think we need to resolve this ajax tag issue before 2.0 goes GA. The AJAX support of Struts 2 gets so much attention by the community that to have a brittle, poorly supported feature that we hope to remove in the next release will only bring confusion and rejection of Struts 2 as a whole. If we created a new tag library, our current tags should be able to be very much simplified as a lot of the attributes would go away. The new tags would be much clearer and easier to pick up without having to explain themes and why certain attributes only work in certain situations. On the other hand, ripping the ajax tags out would affect backwards compatibility. Are a lot of users out there using these tags? Could the migration be simple or would it involve too much effort? Don Ian Roughley wrote: The wrappers around the beans are there to provide accessors to new attributes needed by the ajax tags. If we were to extract the tags into a separate taglib or library, I don't think we would need the wrappers. The additionally required attributes would be contained on the new classes in the new library. This would also remove the dependency of s2 on each ajax library we use (i.e. for dojo we need an additional attribute x & y, for prototype maybe we use y and add new attributes a & b). But I like the idea :) It would also help with the more frequent dojo updates. /Ian Ted Husted wrote: Meanwhile, what about Don's suggestion that we keep the wrappers but drop the theme and put the tags into their own library or plugin? We'd need to do something like that first, regardless of where the code ultimately lives. -Ted. On 12/14/06, Musachy Barroso <[EMAIL PROTECTED]> wrote: Probably a better integration in some places...but it would definitely be worth considering not to duplicate what others are doing. musachy Don Brown wrote: > Well, if there is an external project that already does everything we > want, then why don't we just use them? I'm all for minimizing > duplication. What value does having our own ajax tag library provide? > > Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: We need to clean up the Struts 2 AJAX tags (was Re: Additional UI tags)
Personally, I have only WW2 apps with the ajax theme in production and there is no intention of upgrading anytime soon. I would also be surprised if any of the other committers have projects based on the ajax theme in production. /Ian Ted Husted wrote: On 12/18/06, Ian Roughley <[EMAIL PROTECTED]> wrote: > On the other hand, ripping the ajax tags out would affect backwards > compatibility. Are a lot of users out there using these tags? Could > the migration be simple or would it involve too much effort? I have never gotten much of an answer whenever I queries the users for who was using the ajax tags. Usually, about 3-4 weeks after a new change was made I would get some feedback. Personally, it would seem that most people are either (a) not using them, or (b) rolling their own. I'm not sure how much backward compatibility would be affected - as if the same attributes that are used now could be used in the ajax plug-in tags. So if you are upgrading you'd just need to ensure that the plug-in is there. I haven't checked lately, but I think there is quiet a difference from WW2 to Struts2 for the ajax tags (i.e. new attributes, new dojo version, new tags). If we extract the ajax support into a struts-dojo plugin, it would pave the way for alternative plugins. If the change in ajax support is an issue for someone, then they could roll another plugin based on the struts-dojo plugin. Likewise for other ajax libaries. The key question is whether the Struts committers are using the Ajax theme and how the change is going to affect the applications we have in production. We can't drag around code that people are not going to support, and we can't support code that we don't use ourselves. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: We need to clean up the Struts 2 AJAX tags (was Re: Additional UI tags)
Don Brown wrote: As much as I absolutely hate to say it, I think we need to resolve this ajax tag issue before 2.0 goes GA. The AJAX support of Struts 2 gets so much attention by the community that to have a brittle, poorly supported feature that we hope to remove in the next release will only bring confusion and rejection of Struts 2 as a whole. agreed. If we created a new tag library, our current tags should be able to be very much simplified as a lot of the attributes would go away. The new tags would be much clearer and easier to pick up without having to explain themes and why certain attributes only work in certain situations. Yes - much easier to explain tags. On the other hand, ripping the ajax tags out would affect backwards compatibility. Are a lot of users out there using these tags? Could the migration be simple or would it involve too much effort? I have never gotten much of an answer whenever I queries the users for who was using the ajax tags. Usually, about 3-4 weeks after a new change was made I would get some feedback. Personally, it would seem that most people are either (a) not using them, or (b) rolling their own. I'm not sure how much backward compatibility would be affected - as if the same attributes that are used now could be used in the ajax plug-in tags. So if you are upgrading you'd just need to ensure that the plug-in is there. I haven't checked lately, but I think there is quiet a difference from WW2 to Struts2 for the ajax tags (i.e. new attributes, new dojo version, new tags). Don Ian Roughley wrote: The wrappers around the beans are there to provide accessors to new attributes needed by the ajax tags. If we were to extract the tags into a separate taglib or library, I don't think we would need the wrappers. The additionally required attributes would be contained on the new classes in the new library. This would also remove the dependency of s2 on each ajax library we use (i.e. for dojo we need an additional attribute x & y, for prototype maybe we use y and add new attributes a & b). But I like the idea :) It would also help with the more frequent dojo updates. /Ian Ted Husted wrote: Meanwhile, what about Don's suggestion that we keep the wrappers but drop the theme and put the tags into their own library or plugin? We'd need to do something like that first, regardless of where the code ultimately lives. -Ted. On 12/14/06, Musachy Barroso <[EMAIL PROTECTED]> wrote: Probably a better integration in some places...but it would definitely be worth considering not to duplicate what others are doing. musachy Don Brown wrote: > Well, if there is an external project that already does everything we > want, then why don't we just use them? I'm all for minimizing > duplication. What value does having our own ajax tag library provide? > > Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Additional UI tags
The wrappers around the beans are there to provide accessors to new attributes needed by the ajax tags. If we were to extract the tags into a separate taglib or library, I don't think we would need the wrappers. The additionally required attributes would be contained on the new classes in the new library. This would also remove the dependency of s2 on each ajax library we use (i.e. for dojo we need an additional attribute x & y, for prototype maybe we use y and add new attributes a & b). But I like the idea :) It would also help with the more frequent dojo updates. /Ian Ted Husted wrote: Meanwhile, what about Don's suggestion that we keep the wrappers but drop the theme and put the tags into their own library or plugin? We'd need to do something like that first, regardless of where the code ultimately lives. -Ted. On 12/14/06, Musachy Barroso <[EMAIL PROTECTED]> wrote: Probably a better integration in some places...but it would definitely be worth considering not to duplicate what others are doing. musachy Don Brown wrote: > Well, if there is an external project that already does everything we > want, then why don't we just use them? I'm all for minimizing > duplication. What value does having our own ajax tag library provide? > > Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Additional UI tags
And not to mention that debugging for new users is not a trivial task! /Ian Don Brown wrote: The question is do we want to create one Struts tag library that does everything, or focus on tags that require close ties with our framework? While I like the idea of providing more features and tags to our users, I wonder if within Struts is the best place to host it... Don Ted Husted wrote: I know I've implemented paging a dozen different ways, and reducing to a tag of our own sounds like a good idea. Ditto with sorted tables. If you wanted to contribute the tags, the thing to do would be to file a CLA and open a JIRA ticket with the code attached,. * http://apache.org/licenses/#clas -Ted. On 12/10/06, Tom Schneider <[EMAIL PROTECTED]> wrote: Hello, I've been working with webwork since June. My company migrated from a home-grown webframework to webwork and it has been a very good experience. I'm excited to see how struts2 can improve on an already top-notch framework. In the process of integrating webwork with our software, I implemented several UI tags that probably could be used on other projects. I wanted to get a feel for whether there was a desire to add these tags to the core struts project. Although there are other open source tags that implement this functionality, we leverage the template based nature of the UI tags very heavily and wanted tags that allowed us this type of customization. Pager - the pager tag is used to display a small pager display to allow pagination navigation. (e.g. << < 1 to 6 of 30 > >>) This is used on almost all the pages where we have lists of data. SortColumn - the sort column tag displays the column name, the current sort direction and is hyperlinked so that the sort direction/selected sort column can be changed (e.g. Name ^ or Name v) So, my question is: Is there any interest in adding these kinds of tags to the core struts tag library, or should these be separate? I would think there would be enough other projects out there that would need these types of tags to warrant it, however, I've been doing only database apps for the last 2 years, so my perspective may be skewed a bit. Thanks, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Additional UI tags
This has been my concern for some time now... especially with the dojo / ajax tags. What we seem to be doing is simply wrapping the dojo tag with a s2 tag - providing ways to access the dojo specific attributes. There are then additional issues - such as the dojo code releasing more often then s2 (3 releases I think since ww became s2); not all the attributes of the dojo tag in the s2 taglib; and not all the functionality included (especially advanced functionality). If users then want to upgrade the dojo library themselves, they are forced to deal with possible conflicts - either running 2 different version (one in s2 and another); using one version and possibly breaking the s2 tags; migrating all the tags from s2 taglibs to pure dojo; or simply becoming frustrated and not using the features (which I think is the worse situation). Perhaps this is best left to the dojo html with s:property taglibs for values? /Ian Don Brown wrote: The question is do we want to create one Struts tag library that does everything, or focus on tags that require close ties with our framework? While I like the idea of providing more features and tags to our users, I wonder if within Struts is the best place to host it... Don Ted Husted wrote: I know I've implemented paging a dozen different ways, and reducing to a tag of our own sounds like a good idea. Ditto with sorted tables. If you wanted to contribute the tags, the thing to do would be to file a CLA and open a JIRA ticket with the code attached,. * http://apache.org/licenses/#clas -Ted. On 12/10/06, Tom Schneider <[EMAIL PROTECTED]> wrote: Hello, I've been working with webwork since June. My company migrated from a home-grown webframework to webwork and it has been a very good experience. I'm excited to see how struts2 can improve on an already top-notch framework. In the process of integrating webwork with our software, I implemented several UI tags that probably could be used on other projects. I wanted to get a feel for whether there was a desire to add these tags to the core struts project. Although there are other open source tags that implement this functionality, we leverage the template based nature of the UI tags very heavily and wanted tags that allowed us this type of customization. Pager - the pager tag is used to display a small pager display to allow pagination navigation. (e.g. << < 1 to 6 of 30 > >>) This is used on almost all the pages where we have lists of data. SortColumn - the sort column tag displays the column name, the current sort direction and is hyperlinked so that the sort direction/selected sort column can be changed (e.g. Name ^ or Name v) So, my question is: Is there any interest in adding these kinds of tags to the core struts tag library, or should these be separate? I would think there would be enough other projects out there that would need these types of tags to warrant it, however, I've been doing only database apps for the last 2 years, so my perspective may be skewed a bit. Thanks, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
Do you have the performance numbers that you can share? I'd really be interested in them. Also, since you've considering JSF and performance is the deciding faactor, do you have the performance information between s1, s2 and JSF? /Ian dice wrote: The custom OGNLValueStack made little difference. AFAIK, the majority of the OGNL calls are dealing with the tag parameters in the tag templates which are not simple java properties. It's a pity. I was looking forward to using Struts 2 on our next major project but much like JSF it is too risky from a performance perspective. Back to Struts 1 ... *sigh* Bob Lee wrote: We noticed the same thing. Maybe we should replace it with JSP-EL? (I don't have time to rewrite OGNL myself.) In the mean time, we wrote a custom version of OgnlValueStack. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Value Stack Question
tag should list the stack. Remember that the local vars
(from loops & tags) as well as the model will be on the stack first - so
if the variable has the same name you will need to better specify its
location.
/Ian
Mark Menard wrote:
Is there a means of examining the value stack. I have a very strange
situation where OGNL in my JSP is returning a value from
com.opensymphony.xwork2.ActionContext.parameters on the stack, even though I
have a property with the name on my action class. It's almost like OGNL is
skipping over the property of my action and moving down the stack until it
find my property sitting in the "parameters" Map.
I'd like to be able to dump the stack from top to bottom, listing the names
of the object in the stack, and call toString() and getClass().getName() on
them.
I tried the following in an Interceptor using PreResultListener:
valueStackContext = context.getValueStack().getContext ();
for (Object o : valueStackContext.keySet () ) {
if (o == null) {
System.out.println ("o is null");
} else {
Object value = valueStackContext.get (o);
System.out.println (o.toString() + ": " +
(value == null ? "null" : value.toString () ) );
System.out.println (o.toString() + ": " +
(value == null ? "null" : value.getClass().getName () ) );
}
}
But, I don't see my action on the stack. Stripping out the toString() output
I see the following:
17:35:27,773 INFO [STDOUT] last.bean.accessed: null
17:35:27,773 INFO [STDOUT] struts.actionMapping:
org.apache.struts2.dispatcher.mapper.ActionMapping
17:35:27,773 INFO [STDOUT] com.opensymphony.xwork2.ActionContext.locale:
java.util.Locale
17:35:27,773 INFO [STDOUT] session:
org.apache.struts2.dispatcher.SessionMap
17:35:27,773 INFO [STDOUT] current.property.path: null
17:35:27,773 INFO [STDOUT] attr: org.apache.struts2.util.AttributeMap
17:35:27,773 INFO [STDOUT]
com.opensymphony.xwork2.ActionContext.application:
org.apache.struts2.dispatcher.ApplicationMap
17:35:27,773 INFO [STDOUT] report.conversion.errors: java.lang.Boolean
17:35:27,773 INFO [STDOUT]
com.opensymphony.xwork2.ActionContext.actionInvocation:
com.opensymphony.xwork2.DefaultActionInvocation
17:35:27,773 INFO [STDOUT] last.property.accessed: null
17:35:27,774 INFO [STDOUT] com.opensymphony.xwork2.ActionContext.session:
org.apache.struts2.dispatcher.SessionMap
17:35:27,774 INFO [STDOUT] application:
org.apache.struts2.dispatcher.ApplicationMap
17:35:27,774 INFO [STDOUT]
com.opensymphony.xwork2.ActionContext.parameters: java.util.HashMap
17:35:27,774 INFO [STDOUT] parameters: java.util.HashMap
17:35:27,774 INFO [STDOUT] com.opensymphony.xwork2.ActionContext.name:
java.lang.String
17:35:27,774 INFO [STDOUT] __link: [Ljava.lang.Object;
17:35:27,774 INFO [STDOUT]
com.opensymphony.xwork2.util.ValueStack.ValueStack:
com.opensymphony.xwork2.util.OgnlValueStack
17:35:27,774 INFO [STDOUT] xwork.MethodAccessor.denyMethodExecution:
java.lang.Boolean
17:35:27,774 INFO [STDOUT]
com.opensymphony.xwork2.dispatcher.HttpServletRequest:
org.apache.struts2.dispatcher.StrutsRequestWrapper
17:35:27,774 INFO [STDOUT] xwork.NullHandler.createNullObjects:
java.lang.Boolean
17:35:27,774 INFO [STDOUT]
com.opensymphony.xwork2.ActionContext.conversionErrors: java.util.HashMap
17:35:27,774 INFO [STDOUT]
com.opensymphony.xwork2.dispatcher.ServletContext:
org.apache.catalina.core.ApplicationContextFacade
17:35:27,774 INFO [STDOUT]
com.opensymphony.xwork2.dispatcher.HttpServletResponse:
com.opensymphony.module.sitemesh.filter.PageResponseWrapper
17:35:27,774 INFO [STDOUT] request:
org.apache.struts2.dispatcher.RequestMap
I don't see an instance of my action class, nor an ActionProxy. I do see the
com.opensymphony.xwork2.util.OgnlValueStack. Is that the actual stack that
is used by OGNL to display the view?
Thanks,
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax tags
It's been a while since I've been in dojo code. Will this approach
accommodate multiple forms with multiple submits per form?
/Ian
Musachy Barroso wrote:
I wish it would work, I could get rid of my cell phone :).
What I was trying to say is, that I think it would be better(less
code, easier to use) if the submit were a regular submit, with no
javascript attached, and no ajax theme, then we would use FormBind if
the form is using the ajax theme, like
would be translated into something like:
new dojo.io.FormBind({formNode: dojo.byId("bla")});
What do you think?
musachy
Ian Roughley wrote:
The submit works hand-in-hand with the form in the ajax theme. After
all, you need a button to press to remotely submit a form... I tried
mental telepathy a couple of times but it just didn't work ;)
/Ian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax tags
The submit works hand-in-hand with the form in the ajax theme. After all, you need a button to press to remotely submit a form... I tried mental telepathy a couple of times but it just didn't work ;) /Ian -- From Down & Around, Inc. Innovative IT Solutions Software Architecture * Design * Development ~ web: www.fdar.com email [EMAIL PROTECTED] phone:617.821.5430 ~ Musachy Barroso wrote: I attached an small patch to ww-1484 which will restore the "action" attribute(it was missing only on the tld), fix the div problem and add the 2 missing jsps. I'm still trying to figure out if we really need an ajax submit at all, given that we have an ajax form, any ideas? musachy // by the way what does the /s mean? :) Ted Husted wrote: /s/not broken/now broken On 11/15/06, Ted Husted <[EMAIL PROTECTED]> wrote: Please immediately restore the action attribute, since I expect 80-90% of all Struts 2 applications are not broken against the nightly build. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2 & AJAX only with dojo?
We've talked about this a lot, and I'm still not sure what the correct answer is. At the moment we have a dojo theme (not going to go into the history here - check the webwork mailing list if you're interested). Like any other product it has it's advantages and disadvantages - the same as prototype. However, I'm still not convinced that the ajax themes belong in the core product. There may be particular core elements (i.e. ajax validation) that we include, but others I think should be separate project. What does everyone else think? /Ian -- From Down & Around, Inc. Innovative IT Solutions Software Architecture * Design * Development ~ web: www.fdar.com email [EMAIL PROTECTED] phone:617.821.5430 ~ Rene Gielen wrote: Hi Frank, others, Am Sa, 4.11.2006, 21:49, schrieb Frank W. Zammetti: [...] ... indeed, there is active work being done to integrate DWR that I'm aware of, and also I believe I've seen discussion of AjaxTags integration (although I think that depends on Dojo as well, I may be mistaken there, I haven't kept up lately as well as I'd like). For DWR, it is that the "client side" validation in Struts2/WW is done with DWR (it feels client side because no full request is needed, while in fact it is a server side validation). This integration is already fully functional. In addition, DWR 2 now seems to support direct action invocation for S2/WW. And yes, I think the approach you'd want to take is create a scriptaculous theme (and again, someone will correct me if I'm wrong)... whether it should extend xhtml theme or not I can't really answer because I haven't looked at the theme support in enough detail to know... it doesn't *sound* wrong to me though :) Yes, this should be the way to go, and xhtml would be the right parent to start with. I remember this is not the first time hearing about someone having scriptaculous tag support on his wishlist... if someone would kick this off, maybe others would join the effort? Regards, Rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax tags
dojo's ContentPane, while DivTag wraps HTMLBindDiv(from
struts), and they are quite different. I think we
should
replace HTMLBindDiv with an implementation that extends
dojo's ContentPane and add a timer to it for the auto
refresh.
what do you guys think?
musachy
Ian Roughley wrote:
Yes - this was the direction that we wanted to go
in. Try
to do as much as possible in dojo and provide light
wrappers
in Struts. When we first implemented the tabs, there
was no
such dojo implementation. The one feature that we had
that
you should check that has been implemented in dojo
is the
pub/sub events - so there should be events that each
tabs
listens to to refresh itself.
I think as Don pointed out, we want to keep a very
lightweight wrapper in struts and have all the work
being
done in dojo.
The other big thing that would be a great help is
converting
the code from dojo 0.2 to 0.3 :)
Ian
-
=== message truncated ===
Send instant messages to your online friends http://uk.messenger.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 2.0.1 Quality
0 - Won't have a chance to look at it for another few weeks. /Ian Ted Husted wrote: The Stuts 2.0.1 distribution has been available for over a week. We have a dependency on XWork 2.0.0 beta 1, and it would not be appropriate to mark the Core (and consequently any of the Plugins) "General Availability", but we might at least consider an Alpha or Beta grade. There are no lissues logged against 2.0.1, and the issues logged against 2.0.2 and FUTURE seem to be incremental improvements. The most serious issue seems to be odd caching issues with the FreeMarker templates. * https://issues.apache.org/struts/browse/WW-1473 There is also an issue with the Tiles TLD's being found, but that is one of our new and experimental plugins. * https://issues.apache.org/struts/browse/WW-1467 Both cases seems like the type of known issue that could be tolerated in an Alpha or Beta grade release. In the future, we might want to mark some of the plugins a different grade than the core, but for the purposes of this vote, a single grade for the distribution seems appropriate. Of course, if anyone feels differently, please say so in your reply. The ballot is only a convenience. [ ] +1 Alpha grade for 2.0.1 "all" [ ] +1 Beta grade for 2.0.1 "all" [ ] -1No, let it remain test-build quality. As usual, we welcome votes from all community members. However, only votes from Struts PMC members are binding. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax tags
I'd like to start a thread on that myself early Nov (after I get back from vacation). /Ian -- From Down & Around, Inc. Innovative IT Solutions Software Architecture * Design * Development ~ web: www.fdar.com email [EMAIL PROTECTED] phone:617.821.5430 ~ Don Brown wrote: Well, your help is very appreciated. I would still like to rethink our concept of tags, themes, and ajax support, but it isn't urgent, and anything you can do to help us clean up our ajax tags in the meantime would be great. Thanks for joining the fun :) Don Musachy Barroso wrote: I'm not sure if that would be a good idea, the thing is that it would add a set of dependencies that I don't think are desirable (scriptaculous, prototype, overlib, etc), I don't see ajaxtags going too far in the future if struts supports these simple ajax tags, because most of its users are using struts anyway. If you guys decide to keep the ajax tags I will work on them despite they are in ajaxtags already. I think keeping thin wrappers over dojo's stuff is a good idea. Don Brown wrote: Ok, sounds reasonable. I'm all for offloading the maintaining of code to other projects when possible :) Hmm...I wonder...could your work be improved to allow your tags to be called from velocity and freemarker as well? Currently, IMO, Struts has only half-hearted support for Ajax widgets and while we've talked about a compressive strategy to tackle the problem, it was never enacted upon. I wonder if there is any way to link our projects better so that we can eliminate the overlap Some way of delegating the actual tags to you, but perhaps provide some advanced features that could only be developed when you have control over the server framework...I'm thinking of DWR or JSON views of Struts actions here... Don Musachy Barroso wrote: It doesn't provide anything on top of Dojo right now, it is just a wrapper. Even when it is available using dojo, it is really nice when you get isolated from the js and just have to use a couple of tags on your page. That's what ajaxtags does, wrappers around other widgets(scriptaculous and family) and people are using it a lot. Considering that we are using dojo anyway, and that it is almost done (with not too much effort), I think we should keep it. musachy Don Brown wrote: Ok, I guess my next question is does the tag provide anything significant on top of Dojo? If we are a simple wrapper for Dojo, it might not be worth continuing to support the tabbed pane tag. What do you think? Don Musachy Barroso wrote: Well, dojo's has some of nice things out of the box(they are just hard to figure out given the amount of documentation), tabs can placed on any of the sides, you can have close buttons on the tabs, (either on the tab or on a corner, firefox-style), and they look a lot better by default ;) about WW-1371, I will have to check it out. Don Brown wrote: Cool! Any chance it fixes other tickets like WW-1371? Do you think this should be a new tag or replace the existing? What are the advantages of the new implementation? Don Musachy Barroso wrote: I picked WW-205, (https://issues.apache.org/struts/browse/WW-205) to start playing with and I have replaced the tabbedpanel implementation with dojo's implementation, so far I have the static and dynamic tabs working. I was having so much fun that I didn't stop to ask if this is what you guys want, although it is suggested by Ian Roughley in the bug's comments. musachy Don Brown wrote: The help would be appreciated. Take a look at the tag documentation - http://cwiki.apache.org/confluence/display/WW/Tag+Developers+Guide - and look at the templates themselves in core/src/main/resources/templates There are several ajax-related issues in our JIRA right now, so that would be a very helpful place to start. :) Don Musachy Barroso wrote: Hi all, I was checking out struts 2 yesterday (I'm a 1.2.7 user) and I found that some of the UI tags(tree, tab panel...) overlap with a project that I'm currently maintaining (ajaxtags at http://ajaxtags.sourceforge.net/). I'd like to contribute to the UI ajax tags, so some pointers on where to start or whom to talk to would be appreciated. Ajaxtags is distributed under an apache 2.0 license so we could lift some code if needed. thanks musachy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -
Re: ajax tags
Yes - this was the direction that we wanted to go in. Try to do as much as possible in dojo and provide light wrappers in Struts. When we first implemented the tabs, there was no such dojo implementation. The one feature that we had that you should check that has been implemented in dojo is the pub/sub events - so there should be events that each tabs listens to to refresh itself. I think as Don pointed out, we want to keep a very lightweight wrapper in struts and have all the work being done in dojo. The other big thing that would be a great help is converting the code from dojo 0.2 to 0.3 :) Ian -- From Down & Around, Inc. Innovative IT Solutions Software Architecture * Design * Development ~ web: www.fdar.com email [EMAIL PROTECTED] phone:617.821.5430 ~ Musachy Barroso wrote: I picked WW-205, (https://issues.apache.org/struts/browse/WW-205) to start playing with and I have replaced the tabbedpanel implementation with dojo's implementation, so far I have the static and dynamic tabs working. I was having so much fun that I didn't stop to ask if this is what you guys want, although it is suggested by Ian Roughley in the bug's comments. musachy Don Brown wrote: The help would be appreciated. Take a look at the tag documentation - http://cwiki.apache.org/confluence/display/WW/Tag+Developers+Guide - and look at the templates themselves in core/src/main/resources/templates There are several ajax-related issues in our JIRA right now, so that would be a very helpful place to start. :) Don Musachy Barroso wrote: Hi all, I was checking out struts 2 yesterday (I'm a 1.2.7 user) and I found that some of the UI tags(tree, tab panel...) overlap with a project that I'm currently maintaining (ajaxtags at http://ajaxtags.sourceforge.net/). I'd like to contribute to the UI ajax tags, so some pointers on where to start or whom to talk to would be appreciated. Ajaxtags is distributed under an apache 2.0 license so we could lift some code if needed. thanks musachy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] replacing dojo with yui
yes - a new theme. The only gotcha's I can think of it that new attributes may need to be added into the UI components and model objects to support options for the JS libraries. By using a "yui" theme in the ww:head element (used to do the JS script includes) you can control that only the yui lib's get loaded and not the dojo lib's. /Ian -- From Down & Around, Inc. Innovative IT Solutions Software Architecture * Design * Development ~ web: www.fdar.com email [EMAIL PROTECTED] phone:617.821.5430 ~ David H. DeWolf wrote: I need to utilize yui instead of dojo for ui/ajax. Am I correct in thinking that this is simply a matter of implementing a new theme? Any gotcha's I should be aware of -specifically in regards to making sure that I don't end up using both libraries? Thanks, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts plugins
Do you see plug-in's being used for enhancing the framework features, for adding "modules" to web apps or both? I ask this because the list of possible plug-ins so far see to be framework related. The ordering that Toby suggested seems to make more sense from a web-app perspective (as features of one web-app may depend on another module being loaded), or both? We should also consider annotations. Using annotations would we need the xml file at all? Or should it be included so that we are declaratively specifying what we want to be running, rather than what's in the classpath. /Ian Don Brown wrote: While I appreciate the idea, I don't particularly think that plugins should be deterministic. Perhaps plugin is the wrong word as it brings to mind descriptors, versioning, dependencies, etc. for some people. In this case, I see it as simply a way to organize code and provide default configuration for that code. Anything that is common to multiple plugins should be pushed into the core. Now, since the names of what configuration files are configurable, you could change it to load "struts-default.xml, struts-plugin.xml, struts-plugin-ext.xml, struts.xml" or whatever other files you'd like. From a core framework POV, I think simply loading struts-plugin.xml in a non-deterministic order is fine for our needs. Don tm jee wrote: Hi guys, Just some thoughts, maybe we could have an order parameter introduced eg struts-plugin.xml 10 So we could have control of which plugin gets the priority when loading and we could defined order 1-100 is for struts, custom plugin starts from 101 etc. Ordering for plugins with same ordering would be undefined. The ordering could maybe applied only to plugin (struts-plugin.xml) as we have just one bootstrap configuration (struts.xml) Thoughts? rgds - Original Message From: David H. DeWolf <[EMAIL PROTECTED]> To: Struts Developers List Sent: Thursday, 28 September, 2006 12:15:12 AM Subject: Re: Struts plugins Not sure if this is exactly what you're looking for, but the patch to upgrade from 0.2 to 2.0 exists: https://issues.apache.org/struts/browse/WW-1418 Also, while you're looking at this, here's another patch related to tiles that I'd be interested in: https://issues.apache.org/struts/browse/WW-1450 David Don Brown wrote: Is there any Tiles 2 migration code I can put into a block or does it need to be written yet? I do agree it would be a great candidate. Don Antonio Petrelli wrote: Don Brown ha scritto: The first batch of plugins: 1. Configuration Browser 2. Jasper Reports 3. JFreeChart 4. JSF 5. Pell Multipart handler 6. Sitemesh 7. Struts 1 You forgot Tiles 2 :-) Ciao Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Retain the "!" idiom but disable it by default
-1 - don't depreciate, leave enabled Given that there is still a lot to discuss I think we should leave it enabled. /Ian Ted Husted wrote: On 8/25/06, Jason Carreira <[EMAIL PROTECTED]> wrote: And I'm all for those (or similar ideas). I think everyone is for those, or at least one or the other. The problem is for the current release. The one where people don't want to wait for those new features. The "!" syntax is still in that one, and the question is whether it should be on or off by default. I say off. Just to clarify matters, I thought it would be helpful to elevate Jason's post to a vote. +1 for retaining the "!" idiom but disabling it by default. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Action ! Method syntax (was Freemarker transform name)
I've also used the ! notation extensively, and am disappointed that it is being removed. I find that the 1-1 mapping from the URL to the method on an action is simple to follow and easy to understand. One thing that I have not seen any mention of yet is conflicting mappings - what happens? Which has the priority? What happens if larger application want one to take preference in one circumstance, and a different one under another scenario? I would argue that a sufficiently large application has not been converted to ensure these issues would not arise. As it stands in this moment in time, we have a switch around the ! idiom, because it is a security flaw that people need to understand before enabling, and that's all. I have to say that I still don't really understand why this is a security flaw. I can understand that calling any public method on a class may not be a good thing, but let's face it, actions are *meant* to be called via a URL. If there is a security issue - then it is an application security issue - because the method is NOT doing the required checks to ensure this is a valid request. On more of an implementation / existing knowledge approach - if this is a Stuts to Struts2 conversions, then there will only be one method, the execute() method. If this is a WebWork to Strut2 conversion then the developers should be aware that this feature is available. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Validation
Ted Husted wrote: On 8/3/06, Ian Roughley <[EMAIL PROTECTED]> wrote: This is actually a feature that I like in WW/SAF, granted som times is makes more sense to use it than others, but that is always going to be a design decision. Can you further explain why you have come to the conclusion that they are not good practice? The "advanced" (but indispensible) features of the framework are designed to follow the class hierarchy. We've put in (a lot of) special-case handling to accomodate multiple alaises, but the architectural grain is that a logical action is mapped to a Java class with a single entry point, and the validations, messaging, and type converters are all designed to attach to the class. The first thing that happens when we start using multiple aliases is that we want different validations, messages, or type converters for this alias or that alias. For example, we have special-case handling for several magic aliases to keep validation from firing on "input" and "cancel", and so forth. The cannonical approach would be to have an Input class and a Cancel class, so that they do not inherit validators from some other action. With modern IDEs and modern JDKs, maintaining a class for each action does not seem so great a burden. Maintaining a set of very similiar and largely redundant mappings is a burden, but given wildcards and other features, we can "normalize" the mappings so that we can program-by-difference within the configuration, just as we do with Java classes. I'm not suggesting that try to make it impossible to use multiple alaises. But I am suggesting that the Struts 2 group should recognize that multiple aliases are not a recommended practice, in the same way that chaining actions are not a recommended practice. In many Struts projects I worked on we deliberately modified the functionality to use methods off the same class, and it was one of the reasons that I liked webwork so much. I think it is elegant that you can use one action class for all/most of the CRUD calls, and the interceptors allow for applying / disallowing validation based on the standard method names being used. The reasons you list above would make sense for having some "best practices" for when to use each method, but I wouldn't go as far as saying that it is "not a recommended practice". In webwork I make use of nested packages. Could you explain a bit more about why this is a good practice? Is it synantic sugar, or is the practice providing utility that is not feasible with unnested packages? In a large project there are usually several large divisions, these can then be split into many sub-divisions. Sometimes even further divisions can be made. This is much the same way I use class hierarchies - not too flat, not too deep. Additionally, I find it sometimes useful to add sub-packages for actions that return responses from AJAX calls. I guess this could be called syntactic sugar, but it is good to isolate the URL's and sometimes I want to keep them together rather than have a generic "all-ajax" package. Wildcards would definitely assist, but I think we should still account for nested packages. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] Validation
Ted Husted wrote:
On 8/2/06, Don Brown <[EMAIL PROTECTED]> wrote:
Patrick and I talked about doing that, however, we came up against
several
roadblocks:
1. How would you handle nested packages? For example: /foo/bar/joe?
Do we need to handle nested packages?
In webwork I make use of nested packages.
2. How would you handle action methods?
In the scope of convention over configuraion, I'd suggest that we
don't utilize multiple action methods. I'm coming to the conclusion
that multiple aliases on an action is not a good practice, much like
chaining actions is not a good practice.
If we adopt the perspective that one-method per action is the
cannonical norm, then everything falls into place. The key trouble
with one-method per action is it increases the number of similar
action mappings to maintain. But between wildcards, an extends
feature, and annotations, that problem goes away.
This is actually a feature that I like in WW/SAF, granted some times is
makes more sense to use it than others, but that is always going to be a
design decision. Can you further explain why you have come to the
conclusion that they are not good practice?
3. The case might not always match
Hmmm, I thought the whole idea behind convention over configruation is
that we *make* these things match because they are *suppose* to match.
One possible solution would be to introduce "wildcard modifiers" that
would let
you modify the wildcard-matched value. For example, in problem #3,
you would
want to have "foo/bar" used for the action class "com.acme.{1}.{2}".
You could
apply a modifier like so - "com.acme.{1}.{2|capitalize}" - which would
capitalize the Action name. The idea from these modifiers comes from
Javascript
Templates [1].
The modifiers could solve problems 3 and maybe 1
("com.acme.{1|slashesToDots}.{2|capitalize}"), and perhaps #2 could
be solved by
using the "!" separator instead of the "/" again.
However, the question must be raised whether these improvements
obscure the
somewhat advanced wildcard capability. There is a danger in being
too fancy for
your own good, resulting in a feature that is perceived as too
complicated and
detrimental to the framework. Whether that applies here is up for
discussion.
I'd agree that supporting all fancy alternatives is not a good idea.
The goal should be to solve use cases, not cater to every whim about
what should be upper or lower case.
People who want to fine-tune this sort of thing can use configuration
over convention. Convention over configuration should be for people
who are actually willing to follow a convention.
And, if we use wildcards to define a default convention, there would
be nothing preventing someone from defining another wildcard
convention, suitable to specific needs.
Don
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ApacheCon 2006
I wanted to, but unfortunately had other commits during that period. Good luck and let me know how it goes. /Ian Ted Husted wrote: ApacheCon US has accepted my offer to present a half-day tutorial on Migrating to Struts 2. Is anyone else presenting about Struts this year? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [s2] possible component tags
I'm kinda short on time at the moment myself. /Ian Jason Carreira wrote: :-) I wasn't the one volunteering... Putting the tree tag in took a lot of time, and I didn't even document it ;-) I'd say these can wait. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=37315&messageID=73209#73209 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL - Getter and setter types must match
I'd be up for lifting the restriction, but I also don't have access to the code. /Ian Bob Lee wrote: Thanks for the explanation. What a silly restriction. Anybody up for removing it? I don't have access to the OGNL source. Bob On 6/27/06, Ian Roughley <[EMAIL PROTECTED]> wrote: I've come across this also, and the way I explained it was that it had something to do with matching getters and setters to be well formed java beans. Although I never took the time to look into it further. /Ian Bob Lee wrote: > I've run into this problem with OGNL where I want it to invoke a > setter, but > if there's a getter method with the same property name but a different > type, > OGNL will just fail silently. Why does it even care about the getter? > Anyone > have an idea of what's going on here? > > I'm working against the OGNL version that went out w/ WW 2.2.2. > > Bob > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL - Getter and setter types must match
I've come across this also, and the way I explained it was that it had something to do with matching getters and setters to be well formed java beans. Although I never took the time to look into it further. /Ian Bob Lee wrote: I've run into this problem with OGNL where I want it to invoke a setter, but if there's a getter method with the same property name but a different type, OGNL will just fail silently. Why does it even care about the getter? Anyone have an idea of what's going on here? I'm working against the OGNL version that went out w/ WW 2.2.2. Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Friday] GWT/Struts - does it make sense?
Martin - I think we are saying the same thing - and I think you confirm this in your last paragraph. Rather than web frameworks, using GWT I think developers are more likely to integrate directly with XWork (as a generic command infrastructure, rather than a web front controller), Spring or the business logic directly. This avoids adding abstraction layers to the design/architecture that don't contribute anything useful in the way of functionality. /Ian Martin Cooper wrote: On 6/23/06, Ian Roughley <[EMAIL PROTECTED]> wrote: I have been thinking about this a lot lately, and I would say that GWT is more likely to replace web frameworks than work with them. I wouldn't phrase it quite like that. It's more like AJAX in general changes the way in which we build the server side of web apps, and GWT demonstrates that more dramatically than many people have seen before. If you really buy into the AJAX way of building web apps (i.e. not just adding tweaky bits to existing apps), then the most dramatic change is that you find yourself writing very little server side code. (I'm not talking about the "business logic" here, only what sits on top of it.) Once you have something in place that deserialises requests and serialises responses (which GWT provides with their RemoteServiceServlet), then almost all you have left to do is implement CRUD operations on top of the business logic. At my last company (meaning up until a week ago), perhaps only 10% of the code we wrote for our newest app is server side Java code. I did put Struts 1.3 in place early on, but we ended up with exactly two action mappings for the entire app. (We have two only because we're using two different client-side technologies; one mapping would be the norm.) As for using Struts with GWT, I'm not sure that I see the point. You could, yes, but why would you? You'd either have to provide your own code to do all of what their RemoteServiceServlet does, or you'd have to futz with the client side code so that it doesn't use it, and basically reinvent the way in which RemoteServiceServlet works anyway. On the surface, that might not seem so hard, but if Google has done its job properly, there's a lot more to it that there might appear. -- Martin Cooper /Ian -- From Down & Around, Inc. Innovative IT Solutions Software Architecture * Design * Development ~ web: www.fdar.com email [EMAIL PROTECTED] phone:617.821.5430 ~ Michael Jouravlev wrote: >> From another thread: > > On 6/23/06, Sean Schofield <[EMAIL PROTECTED]> wrote: >> JSF is a major shift in the way we've been doing things. >> It will take a while for everyone to understand JSF enough >> before they are ready for Shale. > > I think that it should not be too complex to combine GWT front end > with Struts backend. I haven't tried it yet but does it really matter, > pure servlet or Struts Action, it is just a URL after all. GWT is new > and fun, yet it might allow to reuse existing skills if not code. > Struts would be used for server-side validation, model/database > access/update, state management. > > Looking into Ajax future I think that from both developer and user > perspective GWT/Struts can be a sensible option for rich web > applications in comparison with JSF/Shale/ICEFaces/whatnot. Opinions? > > I know, I know, "It is up to you to make it happen" ;-) > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Friday] GWT/Struts - does it make sense?
I have been thinking about this a lot lately, and I would say that GWT is more likely to replace web frameworks than work with them. /Ian -- From Down & Around, Inc. Innovative IT Solutions Software Architecture * Design * Development ~ web: www.fdar.com email [EMAIL PROTECTED] phone:617.821.5430 ~ Michael Jouravlev wrote: From another thread: On 6/23/06, Sean Schofield <[EMAIL PROTECTED]> wrote: JSF is a major shift in the way we've been doing things. It will take a while for everyone to understand JSF enough before they are ready for Shale. I think that it should not be too complex to combine GWT front end with Struts backend. I haven't tried it yet but does it really matter, pure servlet or Struts Action, it is just a URL after all. GWT is new and fun, yet it might allow to reuse existing skills if not code. Struts would be used for server-side validation, model/database access/update, state management. Looking into Ajax future I think that from both developer and user perspective GWT/Struts can be a sensible option for rich web applications in comparison with JSF/Shale/ICEFaces/whatnot. Opinions? I know, I know, "It is up to you to make it happen" ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Struts really need two frameworks? (long)
If the goal is to separate the life cycles or to share code, then I am all for it. But I don't think the end users perception is going to be any different by this proposed change. The question is still going to be "are we going to use a JSF or action framework?" Struts is not advocating a preference (and I don't think it should) and I believe this is the confusion for most people when making a choice. /Ian Don Brown wrote: Ted Husted wrote: As for making the UI tags an independant extension, a al Tiles, that sounds good too. (Even better if we include the "value added" Ajax support.) But I don't know if we want to hold back the SAF 2.0.0 to make it happen. But, for phase 2, sure! Actually, I'm thinking splitting off the tags would help us get SAF 2.0.0 out the door sooner. A lot of our remaining tickets are for AJAX tags, which would be in this new project. As for the Tiles comparison, that is exactly what I was going for. And to be clear, the tags, at least for the near term, would stay dependent on Struts Action 2. The reason to split them off would be to give them their own release cycle and make Struts Action 2 releases more focused and quicker. The tags have their own group of interested committers, so I don't see a repeat of our last spinoff attempt. :) Don -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SAF2 Automatic AJAX Support
Thanks for all the work Frank! I am definitely going to take a look next week. /Ian Frank W. Zammetti wrote: As per the previous discussions, JIRA ticket is created: http://issues.apache.org/struts/browse/WW-1330 This is an addition to SAF2 that will allow incoming XML or JSON messages to be automatically parsed and the target Action populated from it. It also provides the capability to generate JSON or XML from an Action as the response to the client. This is implemented as two new Interceptors, two new Results, and two new *Aware marker interfaces (plus one helper class). Attached to the ticket is all the new code. Note the link in the comments to download the full sample/test app, which is ready to drop in an app server and fire up, including full javadocs, build script, etc. I highly suggest anyone interested grab that and give it a go. Feedback welcome :) Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Upgrade Dojo toolkit
I guess my point of view, which I thought others shared at JavaOne (please speak up, because I'm starting to think that I am imagining it :)), is this: 1. For very basic wrapped widgets the dojo implementation is great. But, as soon as people start working more in depth, problems arise and in-depth knowledge of the dojo framework is required. I believe Pat's examples of this was debugging issues. This no longer allows us to wrap and isolate the end user. 2. I think we are doing a lot of work wrapping the dojo widgets with tag object models, etc. when the alternative is easier - add .. /> tags directly to the dojo markup. I also believe as more complex UI's are build, most people will opt. for this route for more control. 3. Using #2 above we are not forcing user to either use the dojo version in the SAF release, or to muck about updating the dojo version themselves - currently the dojo JS is included in the core JAR file. Not being able to easily use the most recent version (with the most recent bug fixes) is most likely gong to be frustrating. 4. When it comes down to it, SAF is adding no additional functionality to the dojo widgets. There was a discussion about PDF's the other week, and I think this is similar issue. 5. If we add any ajax functionality it should tie into the framework - i.e. validation and connecting custom componts/rendering with actions. In these cases I think that DWR is a better option than dojo /Ian Frank W. Zammetti wrote: I've done a bit of work with both DWR and Dojo, so... DWR is really fantastic in terms of being really easy and clean to write to. It makes remote calls to the server look like nothing more than function calls to a local Javascript object. Really sweet. But, that's all it is. While that's great (I'm a fan of DWR if you couldn't guess!) it doesn't provide a component model for building widgets, as Dojo does. It doesn't inherently have anything to say about that. You *could* of course build widgets with DWR, but it would require coming up with your own component model, and all the plumbing that goes into that. Dojo already has that. My feeling is that DWR is more advanced in terms of just doing AJAX. But, when you start talking about GUI widgets specifically, Dojo has a big leg up IMO. I'm not sure what that really says about either library's place in SAF2 though... Frank On Mon, June 19, 2006 10:25 am, tm jee wrote: Instead these components would fall into an "extra" project, separate from the core project. Is it possible to have it remain in core, I am willing to maintain and improve them. About using dwr as the officianl ajax tool / util, i am not sure how components could be build around it. Would it be too much efford to build components around dwr or are we looking on something else. (I have almost no knowledge about dwr :-P so i might be totally off ) regards. - Original Message From: Ian Roughley <[EMAIL PROTECTED]> To: Struts Developers List Sent: Monday, 19 June, 2006 8:52:45 PM Subject: Re: [action2] Upgrade Dojo toolkit My understanding from the meeting was that we would not pursue components that simply wrapped other components (i.e. dojo widgets). Instead these components would fall into an "extra" project, separate from the core project. /Ian tm jee wrote: Hmm what about the ajax component support? Are we going to make them work with dwr instead of dojo? or just dropping them rgds - Original Message From: Ian Roughley <[EMAIL PROTECTED]> To: Struts Developers List Sent: Sunday, 18 June, 2006 11:22:26 PM Subject: Re: [action2] Upgrade Dojo toolkit At JavaOne it was decided to go with DWR in favour of dojo. Given this I would assume that we would not upgrade the version. /Ian tm jee wrote: Hi guys, Is there any plan to upgrade dojotoolkit from the current 0.2.2 to 0.3.x? 0.3.x have lots of really cool stuff and from the bugs list, it looks like lots of bugs have been fixed. Cheers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Upgrade Dojo toolkit
Could you expand on the benefits? - I've not had time to follow much lately. /Ian -- From Down & Around, Inc. Innovative IT Solutions Software Architecture * Design * Development ~ web: www.fdar.com email [EMAIL PROTECTED] phone:617.821.5430 ~ Martin Cooper wrote: On 6/18/06, Ian Roughley <[EMAIL PROTECTED]> wrote: At JavaOne it was decided to go with DWR in favour of dojo. Given this I would assume that we would not upgrade the version. I don't believe we decided to get rid of Dojo completely, so as long as Dojo is in the mix, we should definitely upgrade from 0.2.2 to 0.3. There are huge changes in 0.3 that we would definitely want for anything we do do with Dojo. -- Martin Cooper /Ian tm jee wrote: > Hi guys, > > Is there any plan to upgrade dojotoolkit from the current 0.2.2 to 0.3.x ? > > 0.3.x have lots of really cool stuff and from the bugs list, it looks like lots of bugs have been fixed. > > Cheers. > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
