Re: [Standalone Tiles] Progress
Greg Reddin ha scritto:
I've added a preliminary version of a TilesContext interface and
refactored the core API to use it. .
Note that I ran out of time before I had a chance to look at these
other examples, so if you look at what I just committed and inherently
see a better way, please share.
Hi Greg
I am working on an idea that involves Contexts and Scopes (in fact the
product I want to release will be called "Scopes" ;-) ) without being
tied to any framework.
What I created is a "State" that comprises a certain number of
"Contexts" that have a similar API to ServletRequest, HttpSession and
ServletContext (I mean they all have "getAttribute" and "setAttribute"
methods).
"State.getContext(String contextName)" method is used to retrieve the
context, i.e. you can call it such as:
state.getContext("request") to get request context.
The engine creates the State through the use of a serlvet filter and
uses a wrapped HttpServletRequest to deliver it to servlets.
I don't know if it is useful. You know, I wish to publish it with Apache
License on Sourceforge but I still did not register a project for it,
because I wanted to write a bit of docs first. But anyway if you are
interested on it I can post it ASAP.
Anyway I really liked the idea of TilesContext. Just a thought... what
do you think about using it in ComponentDefinitions.getDefinition
methods? I noticed that your TilesContext has a map for headers, that I
use to read for detecting the device
Ciao
Antonio
P.S. I also managed to add "window" scope but that is another story.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Public API first draft
The JDK1.5 api looks really great. I'm not native english but is this interface name correct? Validatable Should it not be? Validateable /Claus - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29317&messageID=56886#56886 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dear trolls...
Then you are saying that a different approach would not be popular? So to restate it, what is going here is popular. Oh good. Last thing I want is something strange. Life just anint' fair, is it now. Maybe you are imagining that you hired some of the people on this list, and that they would work for you and then you could draw something on the board, and they would be willing to implement it. A big salary they get I imagine. Let me tell you a true story: I had a client draw something on a board for me. I said I was going to the bathroom; took my car keys... and took the elevator instead. I did not return their calls. So how desperate would these qualified people have to be you think? If they enjoy their work, great for us. If that means they want to work in a certain way... I guess deal with it or don't. .V Jonathan Revusky wrote: Granted, you can always fork off your own version of Struts and work on it somewhere else, but the point is that it will only get a very small fraction of the attention and usage of the canonical version on struts.apache.org. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dear trolls...
I am not sure if I want you to walk up to me and say: "Would you sign my copy of Catcher in the Rye please?" You do have it, don't you? .V Dakota Jack wrote: This is silly, whomever you are. On 5/3/06, netsql <[EMAIL PROTECTED]> wrote: "and that is why you will kill me last"? :-0 .V Dakota Jack wrote: > > At least you are civil. That part is good. > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Public API first draft
Ok, I remember us saying we wanted to clean up a lot of things that weren't right in the old codebase, but why are we changing everything just for the sake of change? Instead of having a pretty good sized community who can easily switch over with a few tweaks (the WebWork community) and a huge community to write a compatibility layer and migration docs for, we'll have almost no-one who can try out the code on a real-world project for a considerable time. It took my project a couple of weeks of tracking down little things to go from the 2.1.x codebase to 2.2, and that was all in WebWork, without huge API changes! Plus, I don't see a lot of these changes as being better, just different. The messages, for instances. Messages in WebWork work really well... So why are we changing them? Why the requirement to use message keys? At work we only use message keys, but that's not the case everywhere. Sometimes it's quicker and easier to just throw some text in there for the message. Anyway, needless to say I'm not too excited to see these changes... It will make the timetable for converting my project over look more like 6 months instead of 1 month since we don't have time to make this many changes. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29317&messageID=56953#56953 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Public API first draft
Jason brings up a great point. Is Struts2 meant to be a "mostly" compatible upgrade from webwork 2.2.2, or is it to be similar to the upgrade from Struts? We have spoken about correcting the API, but I do not think this question has ever been asked. I think we have also been saying that if you want to get a kickstart on Struts2, use webwork as their will be only small changes - if this is not the case we need to start setting expectations now. As far as the API is concerned, the only question I have is do you think that the forField() and forRequest() methods should be more generic? i.e. if flash scope or workflow scope is added, additional methods would be needed. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29317&messageID=56959#56959 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Public API first draft
> Jason brings up a great point. Is Struts2 meant to > be a "mostly" compatible upgrade from webwork 2.2.2, > or is it to be similar to the upgrade from Struts? > We have spoken about correcting the API, but I do > not think this question has ever been asked. I > think we have also been saying that if you want to > get a kickstart on Struts2, use webwork as their > will be only small changes - if this is not the > case we need to start setting expectations now. Afaict, it was said that SAF2.0 would be a ww 2.2.2 with additional enhancements to make easy upgrades for 1.x possible ( a 'drop-in replacement' ). WW 2.2.2 users would only have to do a search & replace of the package names. I too expect(ed) an easy ww2.2.2 -> saf2.0 migration. If not, we should port over any bugfixes from the saf2 repository to the ww2 repository, for those who need ww2.2.2 fixes, but can't upgrade because the 'easy migration to saf2' turns out to be a bit more difficult that expected. > As far as the API is concerned, the only question I > have is do you think that the forField() and > forRequest() methods should be more generic? i.e. if > flash scope or workflow scope is added, additional > methods would be needed. Cheers, Phil - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29317&messageID=56962#56962 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Public API first draft
I'm -1 on the draft proposal. The vast majority of the API as I read it is to support Bob's proposal of how to deal with XWork. As Patrick stated before (paraphrase) the three proposals are: 1) Move XWork over as a seperate project under the umbrella of Struts Action 2 (Webwork=>Struts "web" and XWork=>Struts "core") 2) Create an adapter layer for Struts 2 developers to use without directly interfacing XWork (Bob's proposal) 3) Leave XWork where it is and use XWork's API directly in Struts Action 2 The public API presented mainly implements #2, which has not yet built a consensus that it should be used. In my view, the problems with #2 are: 1) It creates an adapter code layer that adds little functionality but requires maintenance. For example, if something is added in XWork, then a change in Struts 2 will generally be required for that change to be usable. 2) If it does add functionality, it blurs the traditional seperation of roles between XWork and Webwork. The adapter layer risks becoming a second judgement layer on what should or should not be in XWork. I think those decisions should be made in the XWork project directly. 3) If we are going to use XWork's API so directly and are worried about it being called "opensymphony.xwork" rather than "apache.struts", we should simply move XWork over as in proposal #1. 4) It creates a divide of those things that are part of the Adapter pattern layer and those that are not. Those that are not become more obscure and undocumented. Thus, while I applaud Bob and Patrick for putting out a vision in code, since it appears to me that 90% of the API simply supports proposal #2, we should discuss that proposal instead first before creating an API that supports it. Gabe - Original Message From: Patrick Lightbody <[EMAIL PROTECTED]> To: dev@struts.apache.org Sent: Wednesday, May 3, 2006 10:01:58 PM Subject: [action2] Public API first draft Bob and I have been going over the new public API proposal. It has been designed to simplify Struts and abstract away XWork complexities that aren't needed. It is far from complete, but we wanted to get some early feedback. We'll likely be talking about this stuff a lot more during JavaOne, but we'd like to start the discussions now. The code is checked in under the action-api module. Assuming you've got the basic Maven build running, you can generate the JavaDocs (which might make seeing the API easier) by running: mvn javadoc:javadoc >From the action-api directory. You must have run "mvn install" at least once >before for that to work. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29317&messageID=56817#56817 - 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] Public API first draft
On 5/4/06, Claus Ibsen <[EMAIL PROTECTED]> wrote: The JDK1.5 api looks really great. I'm not native english but is this interface name correct? Validatable Should it not be? Validateable Neither of these is an English word... ;-) -- Martin Cooper /Claus - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29317&messageID=56886#56886 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA links to Subversion commits
On 5/3/06, Jeff Turner <[EMAIL PROTECTED]> wrote: On Wed, May 03, 2006 at 08:00:43PM -0700, Martin Cooper wrote: > On 5/3/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: > > > > The Subversion plugin for JIRA seems to be installed, but it's not > > working. > > > Weird. It seems to be working _sometimes_. For example: > > http://issues.apache.org/struts/browse/WW-1278 > > I don't know if there's something that we're missing, and I don't have > access to the properties file (that I know of). An infra ticket, perhaps? Only the incubator (webwork) svn tree is being parsed. I'll update the config file so that the rest of struts is parsed too. Aha! Of course - I was forgetting we have two SVN trees right now. Thanks, Jeff! -- Martin Cooper --Jeff > -- > Martin Cooper > > >For example: > >http://svn.apache.org/viewcvs?rev=398085&view=rev > >http://issues.apache.org/struts/browse/STR-2852?page=all > > > > This page says there is a properties file to edit, and I wonder if > > that was done for our installation. > > * http://confluence.atlassian.com/display/JIRAEXT/JIRA+Subversion+plugin > > > > Is this something that someone here can check? > > > > -- > > Wendy > > > > - > > 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]
SAF 1.3.x and legacy RequestProcessor
Looking at 1.3 internals (at last) I've found that it contains both ComposableRequestProcessor (CRP) and legacy RequestProcessor (RP). Is this duality really needed? For a regular Struts user who does not extend RP, the new CRP should work just like the old one. The only difference is the config files. Dragging legacy RP along seems like a burden to me, especially that the main difference between 1.2 and 1.3 is the chain of commands, so unless someone wants to make explicit use of chain, there is no reason to upgrade to 1.3. In future, the RP will either have to be supported all along (is it reasonable?) or deprecated (why not do it now?). Am I not getting something? Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SAF 1.3.x and legacy RequestProcessor
At 8:07 AM -0700 5/4/06, Michael Jouravlev wrote: Looking at 1.3 internals (at last) I've found that it contains both ComposableRequestProcessor (CRP) and legacy RequestProcessor (RP). Is this duality really needed? For a regular Struts user who does not extend RP, the new CRP should work just like the old one. The only difference is the config files. Dragging legacy RP along seems like a burden to me, especially that the main difference between 1.2 and 1.3 is the chain of commands, so unless someone wants to make explicit use of chain, there is no reason to upgrade to 1.3. In future, the RP will either have to be supported all along (is it reasonable?) or deprecated (why not do it now?). Am I not getting something? You're right that chain is the main new feature, but there are others that have not been backported to 1.2 (arbitrary properties on all config objects is a nice one) and I doubt there's any interest at all in that backporting. I would be OK with deprecating RequestProcessor. I've been concerned about people using older subclasses of RequestProcessor (like for SSLExt or even Tiles) and then not understanding how using that makes the chain non-functional. Joe -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com "You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new." -- Robert Moog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SAF 1.3.x and legacy RequestProcessor
On 5/4/06, Joe Germuska <[EMAIL PROTECTED]> wrote: At 8:07 AM -0700 5/4/06, Michael Jouravlev wrote: >Looking at 1.3 internals (at last) I've found that it contains both >ComposableRequestProcessor (CRP) and legacy RequestProcessor (RP). Is >this duality really needed? > >For a regular Struts user who does not extend RP, the new CRP should >work just like the old one. The only difference is the config files. > >Dragging legacy RP along seems like a burden to me, especially that >the main difference between 1.2 and 1.3 is the chain of commands, so >unless someone wants to make explicit use of chain, there is no reason >to upgrade to 1.3. In future, the RP will either have to be supported >all along (is it reasonable?) or deprecated (why not do it now?). > >Am I not getting something? You're right that chain is the main new feature, but there are others that have not been backported to 1.2 (arbitrary properties on all config objects is a nice one) and I doubt there's any interest at all in that backporting. I would be OK with deprecating RequestProcessor. Me too. -- Martin Cooper I've been concerned about people using older subclasses of RequestProcessor (like for SSLExt or even Tiles) and then not understanding how using that makes the chain non-functional. Joe -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com "You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new." -- Robert Moog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Public API first draft
I guess I'm a bit confused but is this API the only supported route or are their plans to support existing WebWork/Xwork code? I'll be honest and say that I need to go through the API and consider each point before I make a complete judgement. However, at first glance, this deviates far enough from existing XWork actions to leave me a bit concerned. In regards to the implementation of the API where did ResponseAware go? While not elegant there are times where it is useful. (admittedly I use an interceptor for this for example http://confluence.twdata.org/display/WW/HTTPS+and+IE+Issues so it may be a mute point.) - Eric On 5/4/06, Gabe <[EMAIL PROTECTED]> wrote: I'm -1 on the draft proposal. The vast majority of the API as I read it is to support Bob's proposal of how to deal with XWork. As Patrick stated before (paraphrase) the three proposals are: 1) Move XWork over as a seperate project under the umbrella of Struts Action 2 (Webwork=>Struts "web" and XWork=>Struts "core") 2) Create an adapter layer for Struts 2 developers to use without directly interfacing XWork (Bob's proposal) 3) Leave XWork where it is and use XWork's API directly in Struts Action 2 The public API presented mainly implements #2, which has not yet built a consensus that it should be used. In my view, the problems with #2 are: 1) It creates an adapter code layer that adds little functionality but requires maintenance. For example, if something is added in XWork, then a change in Struts 2 will generally be required for that change to be usable. 2) If it does add functionality, it blurs the traditional seperation of roles between XWork and Webwork. The adapter layer risks becoming a second judgement layer on what should or should not be in XWork. I think those decisions should be made in the XWork project directly. 3) If we are going to use XWork's API so directly and are worried about it being called "opensymphony.xwork" rather than "apache.struts", we should simply move XWork over as in proposal #1. 4) It creates a divide of those things that are part of the Adapter pattern layer and those that are not. Those that are not become more obscure and undocumented. Thus, while I applaud Bob and Patrick for putting out a vision in code, since it appears to me that 90% of the API simply supports proposal #2, we should discuss that proposal instead first before creating an API that supports it. Gabe - Original Message From: Patrick Lightbody <[EMAIL PROTECTED]> To: dev@struts.apache.org Sent: Wednesday, May 3, 2006 10:01:58 PM Subject: [action2] Public API first draft Bob and I have been going over the new public API proposal. It has been designed to simplify Struts and abstract away XWork complexities that aren't needed. It is far from complete, but we wanted to get some early feedback. We'll likely be talking about this stuff a lot more during JavaOne, but we'd like to start the discussions now. The code is checked in under the action-api module. Assuming you've got the basic Maven build running, you can generate the JavaDocs (which might make seeing the API easier) by running: mvn javadoc:javadoc From the action-api directory. You must have run "mvn install" at least once before for that to work. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29317&messageID=56817#56817 - 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] Accept and Graduate WebWork 2 Podling to Struts
On 4/30/06, Ian Roughley <[EMAIL PROTECTED]> wrote: Martin Cooper wrote: > On 4/28/06, Don Brown <[EMAIL PROTECTED]> wrote: >> >> I call a vote that the Struts PMC accept the WebWork 2 podling as having >> met the incubation requirements and thereby be >> accepted by the Apache Struts project as Struts Action 2. > > > A couple of things I noticed on a quick scan: > > * One of the files in the pico package (PicoFilterDispatcher.java) has > only > an ASF copyright, while all the others in the same package also have a > NanoContainer copyright. Did we accidentally zap the latter on that one > file, or did it not come from there? > > * There are still quite a few files that have OS copyrights but not ASF > ones. > > * PortletUrlTagTest.java has a copyright for BEKK Consulting but not > one for > the ASF. Are we sure we're OK for IP on this one? > > * SubmitAjaxTest.java has a copyright for Down & Around, Inc. but not one > for the ASF. Are we sure we're OK for IP on this one? This is mine. I'll be faxing in the IP assignment tomorrow. It has just been recorded by the ASF Secretary. Thanks! -- Martin Cooper > * dtree.css has a copyright for Geir Landrö but not one for the ASF. > Are we > sure we're OK for IP on this one? > > * The file > FieldValidatorsExampleAction-submitClientSideValidationExample-validation.xml (!) > > has a copyright for Your Corporation (!) but not one for the ASF. > > Once these are all squared away, I am +1, but we need to sort these out > first. I'm willing to help do that if someone can verify what needs to > happen. > > -- > Martin Cooper > > > Status: http://incubator.apache.org/projects/webwork2.html >> >> [ ] +1 Let's bring it in, and I'm committed to the project >> [ ] +0 Let's bring it in, but I won't be involved >> [ ] -0 I'd rather not, but I'm not involved, and here's why... >> [ ] -1 Let's not, and here's why... >> >> We welcome votes from all community members, however, only the votes >> of Struts PMC members are binding. >> >> If this vote passes, the Incubator will need to vote for the >> graduation to >> be complete. >> >> Here is my +1 >> >> 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: [VOTE] Accept and Graduate WebWork 2 Podling to Struts
Martin Cooper wrote: On 4/30/06, Ian Roughley <[EMAIL PROTECTED]> wrote: Martin Cooper wrote: > On 4/28/06, Don Brown <[EMAIL PROTECTED]> wrote: >> >> I call a vote that the Struts PMC accept the WebWork 2 podling as having >> met the incubation requirements and thereby be >> accepted by the Apache Struts project as Struts Action 2. > > > A couple of things I noticed on a quick scan: > > * One of the files in the pico package (PicoFilterDispatcher.java) has > only > an ASF copyright, while all the others in the same package also have a > NanoContainer copyright. Did we accidentally zap the latter on that one > file, or did it not come from there? > > * There are still quite a few files that have OS copyrights but not ASF > ones. > > * PortletUrlTagTest.java has a copyright for BEKK Consulting but not > one for > the ASF. Are we sure we're OK for IP on this one? > > * SubmitAjaxTest.java has a copyright for Down & Around, Inc. but not one > for the ASF. Are we sure we're OK for IP on this one? This is mine. I'll be faxing in the IP assignment tomorrow. It has just been recorded by the ASF Secretary. Thanks! Could you pull the test out of the SVN history (I removed it so the vote could continue) and re-add it? Don't forget to change the copyrights. Thanks, Don -- Martin Cooper > * dtree.css has a copyright for Geir Landrö but not one for the ASF. > Are we > sure we're OK for IP on this one? > > * The file > FieldValidatorsExampleAction-submitClientSideValidationExample-validation.xml (!) > > has a copyright for Your Corporation (!) but not one for the ASF. > > Once these are all squared away, I am +1, but we need to sort these out > first. I'm willing to help do that if someone can verify what needs to > happen. > > -- > Martin Cooper > > > Status: http://incubator.apache.org/projects/webwork2.html >> >> [ ] +1 Let's bring it in, and I'm committed to the project >> [ ] +0 Let's bring it in, but I won't be involved >> [ ] -0 I'd rather not, but I'm not involved, and here's why... >> [ ] -1 Let's not, and here's why... >> >> We welcome votes from all community members, however, only the votes >> of Struts PMC members are binding. >> >> If this vote passes, the Incubator will need to vote for the >> graduation to >> be complete. >> >> Here is my +1 >> >> 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]
[Action2] OpenSymphony Maven Repository
In OpenSymhpony's maven repository for pell-multipart, the pom.xml is missing a 4.0.0 This causes some problem when trying to run some of maven2 'lifecycle'. Is it possible for someone to have a look at it. Thx.
Re: [action2] Public API first draft
On 5/4/06, Martin Cooper <[EMAIL PROTECTED]> wrote:
On 5/4/06, Claus Ibsen <[EMAIL PROTECTED]> wrote:
>
> The JDK1.5 api looks really great.
>
> I'm not native english but is this interface name correct?
>
> Validatable
>
> Should it not be?
> Validateable
Neither of these is an English word... ;-)
Yeah, I talked it over with Josh Bloch yesterday. Even though it's not
a real word, we thought it best to keep it because it's been used in
both Struts and WebWork for a long time (not to mention many other
APIs).
As for the spelling, with English there are no hard and fast rules,
but the general rule is to drop the "e". Debate is to debatable as
validate is to validatable.
Barring that, we computed G(n) (the number of results returned by Google):
G("Validateable") = 16.5k
G("Validatable") = 105k
Bob
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Public API first draft
According to the roadmap (or at least the one in my head :)), Struts Action 2 will be implemented in two phases: Phase 1 - Rename WebWork 2 code, implement Struts 1.x support, minor changes Phase 2 - Annotations, Zero XML configuration, new easy development modes, etc The goal of Phase 1 is to get a release out quickly, in the hands of developers, and help them migrate their code quickly. This probably translates into Struts Action 2.0.x. Phase 2 I see stretching out into Struts Action 2.x or even 3.x, as it is where we bring in truely innovative features that make development easier. That said, I'm with Jason that we need to ensure these first changes for Phase 1 aren't too drastic from an end user perspective, but that doesn't mean we shouldn't try to move around and clean up the API. By minor changes, I mean from an end user perspective, not from an architecture perspective, so drastic API changes that have little impact on today's WebWork 2 applications would fit in this category. I see this new API as a proposal, meant to feed discussion and not to be voted on as a whole today. Therefore, let us have a solid discussion on the particulars of the API, and avoid throwing out the abused '-1' votes, as those are meant for official votes and carry an obstructive, negative connotation. Now for my API comments: Overall - I like the clean feel of the API and the concious decisions to minimize the number of interfaces the user needs to be aware of. It seems to have a minimal conceptual surface area [1] that the Wicket folks talk about. o.a.s.action2 - I'd like to hear the design reasoning behind the Messages changes. I liked the use of Maps in the XWork design as it made it easier to work with. On the other hand, encapsulating message operations in the Messages object does reduce the number of message-handling methods required. Perhaps Messages could extend Map? Also, I agree we should continue to support plain Messages, as not all apps need to be localized. I'm not sure I understand the separation of Validatable and ErrorAware. In particular, Validatable only has a validate() method that returns void. Is there really a case you want to validate, but not have errors sent anywhere? I think of the use case of plugging in a different validation engine like commons-validator, and this separation makes it harder. Why not return Messages? o.a.s.action2.attribute - This is again a feature I'd like to hear the design reasonings of. I liked the previous use of Maps as they were easy to test and pass around. Maps can also be extended to provide the automatic synchonrization feature talked about easily. o.a.s.action2.servlet - I like how the servlet-related classes are contained in their own package. This distinction is very important as I plan to be personally using Action 2 mostly for Portlets. o.a.s.action2.spi - Again, I love this separation - move all the framework classes the user rarely deals with out into its own package. I like making ValueStack a first class interface, and the Interceptor changes seem reasonable. I am somewhat concerned about the Request interface though. While the goal of putting everything you need for a request in one object, it seems to be combining too many roles. For one, it has servlet object retrieval methods in there that should be separated, and I'm not sure if it should be handing the execution of actions and interceptors as well. If the goal is to turn this into a Tapestry-like Visitor object which holds all the request state, we should separate out the servlet getters into their own interface to be combined by the user. The more I think about this Request object, I can't help but notice it pushes the roles usually handled by the Action into it. For example, the Request now holds Messages whereas before we had the ValidationAware interface for the Action. I'm wondering if it might be a better plan to decorate a central Request object with these types of interfaces rather than cluttering the Action. It makes the Action only really usable if you extend ActionSupport, otherwise you have a ton of methods to implement, and concievably, you'd want to be sharing these methods with all your actions anyways. Anyways, I'm glad to have something concrete we can discuss and toss darts at. Thanks Bob and Patrick for taking the time to put this together and I look forward to the feedback. Don [1] http://wicket.sourceforge.net/Vision.html On 5/4/06, Jason Carreira <[EMAIL PROTECTED]> wrote: Ok, I remember us saying we wanted to clean up a lot of things that weren't right in the old codebase, but why are we changing everything just for the sake of change? Instead of having a pretty good sized community who can easily switch over with a few tweaks (the WebWork community) and a huge community to write a compatibility layer and migration docs for, we'll have almost no-one who can try out the code on a real-world project for a considerable time. It took my
Re: [action2] Public API first draft
On 5/4/06, Eric Molitor <[EMAIL PROTECTED]> wrote: In regards to the implementation of the API where did ResponseAware go? org.apache.struts.action2.servlet.ServletResponseAware I put these interfaces in a sub package because users should avoid creating dependencies on the servlet API in their actions. Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Why vote twice for a release quality?
I'm preparing to draw the Struts Action 1.3.2 release quality vote to a close, but as I look at the release plan, I see it has us voting twice on the same release for the same quality vote (vote a and b). Why is this? Seems to me one vote should be plenty. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Make base Action class a dispatch action
So long as this statement... "...the proposed feature changes nothing for regular Action users, it changes nothing for old DispatchAction users, but it makes things a lot simpler for those who want to switch to event-based paradigm with as little efforts as possible." ...is true, count me +1. As long as I can take an existing app and have it work without modification (or with trivial mods at worst), I can't think of a reason not to do this. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! On Thu, May 4, 2006 1:53 pm, Michael Jouravlev said: > What we has been brought from the stone ages: > > * Base Action class does not dispatch events > * DispatchAction and its flavors do, but they do not allow a user to > derive an action class from some another user's base action > > What we got now in 1.2.9 and 1.3.1+ : > > * ActionDispatcher resolves the inheritance issue, allowing any action > to dispatch events > * EventActionDispatcher makes dispatching an easy and fun task; it > also allows to separate input phase from render phase, at the same > time it allows to trigger event with links (GET), not only with > buttons (POST). > > What appears to be a logical next step: > > * Stick dispatching features in base Action, thus making all actions > to be dispatch actions. > > Benefits: > > * ActionDispatcher will not be needed. > * Any action will be able to dispatch events. > * This makes a mind shift, making people think more in terms of events > and independent webresources, kind of like .NET's code-behind. > > Minor drawback: > > * only one dispatching behavior can be chosen. Considering all job > done before, we how have best-of-breed EventDispatchAction. Its > features (maybe in some modified manner) should be pushed to base > Action class. For those who rely on old-style DispatchAction or > MappingDispatchAction, they will still be available. > > So, the proposed feature changes nothing for regular Action users, it > changes nothing for old DispatchAction users, but it makes things a > lot simpler for those who want to switch to event-based paradigm with > as little efforts as possible. > > Thoughts? Objections? Suggestions? > > Michael. > > - > 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] Accept and Graduate WebWork 2 Podling to Struts
I'm ok if you want to just remove the copyright. BTW - the copyright assignment form was faxed monday (5/1). /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: Martin Cooper wrote: On 4/30/06, Ian Roughley <[EMAIL PROTECTED]> wrote: Martin Cooper wrote: > On 4/28/06, Don Brown <[EMAIL PROTECTED]> wrote: >> >> I call a vote that the Struts PMC accept the WebWork 2 podling as having >> met the incubation requirements and thereby be >> accepted by the Apache Struts project as Struts Action 2. > > > A couple of things I noticed on a quick scan: > > * One of the files in the pico package (PicoFilterDispatcher.java) has > only > an ASF copyright, while all the others in the same package also have a > NanoContainer copyright. Did we accidentally zap the latter on that one > file, or did it not come from there? > > * There are still quite a few files that have OS copyrights but not ASF > ones. > > * PortletUrlTagTest.java has a copyright for BEKK Consulting but not > one for > the ASF. Are we sure we're OK for IP on this one? > > * SubmitAjaxTest.java has a copyright for Down & Around, Inc. but not one > for the ASF. Are we sure we're OK for IP on this one? This is mine. I'll be faxing in the IP assignment tomorrow. It has just been recorded by the ASF Secretary. Thanks! Could you pull the test out of the SVN history (I removed it so the vote could continue) and re-add it? Don't forget to change the copyrights. Thanks, Don -- Martin Cooper > * dtree.css has a copyright for Geir Landrö but not one for the ASF. > Are we > sure we're OK for IP on this one? > > * The file > FieldValidatorsExampleAction-submitClientSideValidationExample-validation.xml (!) > > has a copyright for Your Corporation (!) but not one for the ASF. > > Once these are all squared away, I am +1, but we need to sort these out > first. I'm willing to help do that if someone can verify what needs to > happen. > > -- > Martin Cooper > > > Status: http://incubator.apache.org/projects/webwork2.html >> >> [ ] +1 Let's bring it in, and I'm committed to the project >> [ ] +0 Let's bring it in, but I won't be involved >> [ ] -0 I'd rather not, but I'm not involved, and here's why... >> [ ] -1 Let's not, and here's why... >> >> We welcome votes from all community members, however, only the votes >> of Struts PMC members are binding. >> >> If this vote passes, the Incubator will need to vote for the >> graduation to >> be complete. >> >> Here is my +1 >> >> 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: [action2] Public API first draft
I agree with Don on almost everything... scary! The exception is the validate() method returning messages... we need a central place where messages are added, not passing them in and out of methods. I was also confused by the Request interface... I thought / expected it was going to be a way to abstract out ServletRequest vs. PortletRequest, but it does a lot of other stuff, too, and ended up confusing me on what the request processing lifecycle was proposed to be... - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29317&messageID=57044#57044 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Public API first draft
I definitely agree that they should be isolated, but glancing through the api I saw RequestAware but not ResponseAware. (I`m reading the copy Don posted and not the version under source control.) On 5/4/06, Bob Lee <[EMAIL PROTECTED]> wrote: On 5/4/06, Eric Molitor <[EMAIL PROTECTED]> wrote: > In regards to the implementation of the API where did ResponseAware > go? org.apache.struts.action2.servlet.ServletResponseAware I put these interfaces in a sub package because users should avoid creating dependencies on the servlet API in their actions. 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: [action2] Public API first draft
Jason Carreira wrote: I agree with Don on almost everything... scary! The exception is the validate() method returning messages... we need a central place where messages are added, not passing them in and out of methods. Ok, what about passing in an instance of Messages, MessagesAware, or something similar? Also, I forgot to mention, I'd like to avoid the use of "Error" when referring to messages, because many times there are errors, warnings, and information messages. I like the ability for validation to raise warnings that don't result in a failure, but allows me to warn the user the value might not be what they were intending. Don I was also confused by the Request interface... I thought / expected it was going to be a way to abstract out ServletRequest vs. PortletRequest, but it does a lot of other stuff, too, and ended up confusing me on what the request processing lifecycle was proposed to be... - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29317&messageID=57044#57044 - 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] Public API first draft
Also, I forgot to mention, I'd like to avoid the use of "Error" when referring to messages, because many times there are errors, warnings, and information messages. I like the ability for validation to raise warnings that don't result in a failure, but allows me to warn the user the value might not be what they were intending. How do you envision that working? Would individual messages have an optional "severity" property? (i.e. "error", "warning", possibly others) Or would there be one bundle of messages for each severity? I've taken to using a generic BusinessProcessResult object (sometimes extended with process-specific details) which carries with it three lists messages: "message," "warning," and "error". (Actually, it can have other lists with arbitrary keys, but those three have "privileged" status in the API.) For our purposes, it could be a "ValidationResult" which gets passed around through the different validators, each of which can add to any of the lists as appropriate. Seems like something which people might not like as a matter of taste, but I've found it pretty handy. It's also a bigger model change from both Struts and Webwork than may be appropriate at this time. In short, I think it's nice to have a "warning" level if we can work out a clean way to support it. Joe -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com "You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new." -- Robert Moog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Public API first draft
How to implement this is a good question. When I use warnings in my application, they aren't displayed on the very next page, but rather collected as the user goes through the wizard. Then, on the last page, the user is asked to confirm the information, and it is here we display the warnings. Support for message scopes makes it more interesting, although I don't know if it is widely used enough to build into Action 2. Don Joe Germuska wrote: Also, I forgot to mention, I'd like to avoid the use of "Error" when referring to messages, because many times there are errors, warnings, and information messages. I like the ability for validation to raise warnings that don't result in a failure, but allows me to warn the user the value might not be what they were intending. How do you envision that working? Would individual messages have an optional "severity" property? (i.e. "error", "warning", possibly others) Or would there be one bundle of messages for each severity? I've taken to using a generic BusinessProcessResult object (sometimes extended with process-specific details) which carries with it three lists messages: "message," "warning," and "error". (Actually, it can have other lists with arbitrary keys, but those three have "privileged" status in the API.) For our purposes, it could be a "ValidationResult" which gets passed around through the different validators, each of which can add to any of the lists as appropriate. Seems like something which people might not like as a matter of taste, but I've found it pretty handy. It's also a bigger model change from both Struts and Webwork than may be appropriate at this time. In short, I think it's nice to have a "warning" level if we can work out a clean way to support it. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Public API first draft
We're using WebWork 2.2 heavily on a handful of projects (OK, a big handful of big projects), so I definitely understand the concerns. I didn't mean to shock anyone. I thought my point of view was clear based on the introduction to the "Rough Spots" page (http://wiki.apache.org/struts/RoughSpots) and the "Action Next++" thread (http://forums.opensymphony.com/thread.jspa?threadID=27183). I'm worried about migrating our WebWork projects, too, but I'm willing to stick with WebWork 2.2 for a little longer and endure a less convenient migration in order to support what's best in the long run. (I also don't think a migration will be as painful as some think.) In the long run, do we want Struts Action 2.0 to be a standard on the same footing as JSF or just another non-JSF framework? I want the former. I want Struts Action 2.0 to be the default choice of major corporations so I can continue to use it for years to come. If you agree, the most important thing is that we get the published API right in the 2.0 release. The published API includes a Java API like we have here, the configuration (along with the implicit interceptor and result names), the tag libraries, etc. Breaking the API in a 2.0.x release is not an option; we'll be stuck with whatever we put out in 2.0. As I said in the "Action Next++" thread, I'd rather not start planning on a 3.0 release. Let's get it right the first time. On 5/4/06, Don Brown <[EMAIL PROTECTED]> wrote: I see this new API as a proposal, meant to feed discussion and not to be voted on as a whole today. Therefore, let us have a solid discussion on the particulars of the API, and avoid throwing out the abused '-1' votes, as those are meant for official votes and carry an obstructive, negative connotation. Exactly. Thanks, Don. o.a.s.action2 - I'd like to hear the design reasoning behind the Messages changes. I liked the use of Maps in the XWork design as it made it easier to work with. On the other hand, encapsulating message operations in the Messages object does reduce the number of message-handling methods required. Perhaps Messages could extend Map? Also, I agree we should continue to support plain Messages, as not all apps need to be localized. - Passing in keys vs. actual messages - I think always passing in keys is one thing Struts got right. Even if you only support one language, abstracting messages out of your code is still a good practice. - Using keys enabled us to do away with the TextProvider interface entirely. - I didn't like having the same set of methods twice: one for errors and one for regular messages. The new design is more object oriented, has shorter method names, enables better reuse of code between errors and normal messages, and leaves the door open to other levels of messages (such as warning). I'm not saying we want to explicitly support arbitrary levels (like JSF does), but we don't want to close the door to it either. - This design doesn't force inheritance. Notice we don't have ActionSupport anymore? If users still want to have the implicit methods, they can statically import them from a support class. The support class implementation would look up the thread local Request and delegate to it. I didn't add this yet because I'm not sure if we really need it. - In the old design, messages were scoped to an action which doesn't work very well when you're chaining and you want to display all the errors from all the actions. I think we want messages to be scoped to the request (i.e. spanning multiple actions). We actually use our own message handling and ignore WebWork's at the moment. - Regarding your Map comment, we've considered having Messages.forFields() return a Map>. Would that work? That would be identical to what WebWork supports today. I'm not sure I understand the separation of Validatable and ErrorAware. In particular, Validatable only has a validate() method that returns void. Is there really a case you want to validate, but not have errors sent anywhere? I think of the use case of plugging in a different validation engine like commons-validator, and this separation makes it harder. Why not return Messages? I've been thinking Validatable should extend ErrorAware, but I wanted to see what you guys thought first. I don't like the idea of validate() return Messages. I never liked the fact that I had to create an errors object in Struts. I also want to be able to easily add validation messages from setters (I like doing field level validation in the setter and cross field validations in validate()). o.a.s.action2.attribute - This is again a feature I'd like to hear the design reasonings of. I liked the previous use of Maps as they were easy to test and pass around. Maps can also be extended to provide the automatic synchonrization feature talked about easily. This is something I've been kicking around since generics came out. Now that we have generics, it seems funny to be passing around a heterogeneously typed m
Re: Public API first draft
On 5/4/06, Eric Molitor <[EMAIL PROTECTED]> wrote: I definitely agree that they should be isolated, but glancing through the api I saw RequestAware but not ResponseAware. (I`m reading the copy Don posted and not the version under source control.) ValidationAware, ErrrorAware, RequestAware, ResponseAware, SomeOtherStuffAware... Are you kidding? I might not understand something (heck, I haven't started with WW yet), but if all these interfaces are only meant to implement a callback method in a custom class for the framework to call, then... well, I do not like this. For the lifecycle, I want a clear definition of lifecycle call sequence and an option to call lifecycle methods explicitly. All of them. Like in SAF1, WW binds URL to a mapping to an action, so action is the endpoint which is guaranteed to be called. Fine. Then just pass control to that action and give me an option to call all (or some) lifecycle methods explicitly from the action. I will not need interceptors in this case, by the way. And I will not need to implement a bunch of intefaces. For the regular typecasting I agree, some interfaces are needed, to make certain methods available, but there should be a very limited number of these interfaces, and at best a particular class will need to implement only one interface. Um, does it make sense? Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Public API first draft
> > Ok, what about passing in an instance of Messages, > MessagesAware, or something > similar? > Well, currently the validators are passes a ValidatorContext when they are created. The ValidatorContext includes methods for adding messages as well as methods for getting localized texts, etc. > Also, I forgot to mention, I'd like to avoid the use > of "Error" when referring > to messages, because many times there are errors, > warnings, and information > messages. I like the ability for validation to raise > warnings that don't result > in a failure, but allows me to warn the user the > value might not be what they > were intending. > Yes, that's what the difference of the *errors, *warnings, and *messages does in the current ValidationAware interface (implemented by ActionSupport via delegation to a ValidationAwareSupport instance). - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29317&messageID=57068#57068 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Public API first draft
> > How do you envision that working? Would individual > messages have an > optional "severity" property? (i.e. "error", > "warning", possibly > others) Or would there be one bundle of messages for > each severity? > > I've taken to using a generic BusinessProcessResult > object (sometimes > extended with process-specific details) which carries > with it three > lists messages: "message," "warning," and "error". > (Actually, it can > ave other lists with arbitrary keys, but those three > have > "privileged" status in the API.) > > For our purposes, it could be a "ValidationResult" > which gets passed > around through the different validators, each of > which can add to any > of the lists as appropriate. > > Seems like something which people might not like as a > matter of > taste, but I've found it pretty handy. It's also a > bigger model > change from both Struts and Webwork than may be > appropriate at this > time. Actually it's no change at all :-) See my response to Don. Here's the types of methods in there: void setAction[Errors|Warnings|Messages](Collection messages); Collection getAction[Errors|Warnings|Messages](); void setFieldErrors(Map errorMap); /** * @return Map with errors mapped from fieldname (String) to Collection of String error messages */ Map getFieldErrors(); void addAction[Error|Warning|Message](String message); void addFieldError(String fieldName, String errorMessage); boolean hasAction[Errors|Warnings|Messages](); /** * @return (hasActionErrors() || hasFieldErrors()) */ boolean hasErrors(); boolean hasFieldErrors(); > > In short, I think it's nice to have a "warning" level > if we can work > out a clean way to support it. > > Joe > Oops... just noticed it doesn't have "Warnings" in there, but it would be very easy to add. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29317&messageID=57069#57069 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Public API first draft
On 5/4/06, Bob Lee <[EMAIL PROTECTED]> wrote: - Passing in keys vs. actual messages - I think always passing in keys is one thing Struts got right. I presume you meant Struts Action Framework 1 ;-) Even if you only support one language, abstracting messages out of your code is still a good practice. Passing actual message is a nice-have for quick projects or for intranet one-language projects. - I didn't like having the same set of methods twice: one for errors and one for regular messages. The new design is more object oriented, has shorter method names, enables better reuse of code between errors and normal messages, and leaves the door open to other levels of messages (such as warning). I'm not saying we want to explicitly support arbitrary levels (like JSF does), but we don't want to close the door to it either. Is it possible to assign different prefixes to messages generated by different actions? This may be helpful if a page contains several components, each component is controlled by its own action (or a set of actions), so when a component is updated in Ajax mode (or the whole page is reloaded) the messages will be displayed in the proper places. I mean, every component should display only its own messages. - In the old design, messages were scoped to an action which doesn't work very well when you're chaining and you want to display all the errors from all the actions. I think we want messages to be scoped to the request (i.e. spanning multiple actions). We actually use our own message handling and ignore WebWork's at the moment. SAF1 already have had messages request-scoped. This does not work for Redirect-after-post stuff, so SAF1 now has session-scoped messages, that are removed from the session automatically after they are displayed. This is kind of FlashScope for poor. I suggest to have a real FlashScope for messages and other stuff. This may have less importance if WW UI will be Ajax only. Also, considering that in WW action and actionform is one thing, I would say that action-scoped messages are better: messages and actual data that was validated, are stored at the same place. Messages belong to a particular data set of a particular component (action). I experimented with ActionForm-scoped messages in SAF1, having session-scoped ActionForms. Works well in terms that when you reload the page, here is your invalid data, and here are the corresponding errors. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Public API first draft
Actually my point was the Servlet*Aware interfaces should be isolated as their use is generally a bad practice. There was some confusion as to what RequestAware was doing. If you have to implement 35 interfaces to implement an action then obviously this would not be a viable framework. In most cases you would be using few, if any, of the interfaces. Cheers, Eric On 5/4/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: On 5/4/06, Eric Molitor <[EMAIL PROTECTED]> wrote: > I definitely agree that they should be isolated, but glancing through > the api I saw RequestAware but not ResponseAware. (I`m reading the > copy Don posted and not the version under source control.) ValidationAware, ErrrorAware, RequestAware, ResponseAware, SomeOtherStuffAware... Are you kidding? I might not understand something (heck, I haven't started with WW yet), but if all these interfaces are only meant to implement a callback method in a custom class for the framework to call, then... well, I do not like this. For the lifecycle, I want a clear definition of lifecycle call sequence and an option to call lifecycle methods explicitly. All of them. Like in SAF1, WW binds URL to a mapping to an action, so action is the endpoint which is guaranteed to be called. Fine. Then just pass control to that action and give me an option to call all (or some) lifecycle methods explicitly from the action. I will not need interceptors in this case, by the way. And I will not need to implement a bunch of intefaces. For the regular typecasting I agree, some interfaces are needed, to make certain methods available, but there should be a very limited number of these interfaces, and at best a particular class will need to implement only one interface. Um, does it make sense? Michael. - 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] Public API first draft
> We're using WebWork 2.2 heavily on a handful of > projects (OK, a big > handful of big projects), so I definitely understand > the concerns. > > I didn't mean to shock anyone. I thought my point of > view was clear > based on the introduction to the "Rough Spots" page > (http://wiki.apache.org/struts/RoughSpots) and the > "Action Next++" > thread > (http://forums.opensymphony.com/thread.jspa?threadID=2 > 7183). > > I'm worried about migrating our WebWork projects, > too, but I'm willing > to stick with WebWork 2.2 for a little longer and > endure a less > convenient migration in order to support what's best > in the long run. > (I also don't think a migration will be as painful as > some think.) > > In the long run, do we want Struts Action 2.0 to be a > standard on the > same footing as JSF or just another non-JSF > framework? I want the > former. I want Struts Action 2.0 to be the default > choice of major > corporations so I can continue to use it for years to > come. > > If you agree, the most important thing is that we get > the published > API right in the 2.0 release. The published API > includes a Java API > like we have here, the configuration (along with the > implicit > interceptor and result names), the tag libraries, > etc. > > Breaking the API in a 2.0.x release is not an option; > we'll be stuck > with whatever we put out in 2.0. As I said in the > "Action Next++" > thread, I'd rather not start planning on a 3.0 > release. Let's get it > right the first time. I think this is the core decision that needs to be made right now. I'm not sure which way I'm leaning on this, but we need to pick a direction. If we're going to redesign the API and get things right, then lets decide to do that and re-open WebWork to bug fixes and more releases in the meantime. Either way I'd like to push some of this stuff into XWork, not just leave it in SAF2. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29317&messageID=57075#57075 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Public API first draft
I agree both that this is the core decision that has to be made now and that we should push some of this stuff into XWork. I won't vote though, because I've learned we're discussing not voting :-D - Original Message From: Jason Carreira <[EMAIL PROTECTED]> To: dev@struts.apache.org Sent: Thursday, May 4, 2006 4:52:48 PM Subject: Re: [action2] Public API first draft I think this is the core decision that needs to be made right now. I'm not sure which way I'm leaning on this, but we need to pick a direction. If we're going to redesign the API and get things right, then lets decide to do that and re-open WebWork to bug fixes and more releases in the meantime. Either way I'd like to push some of this stuff into XWork, not just leave it in SAF2. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29317&messageID=57075#57075 - 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] Public API first draft
Bob Lee wrote:
o.a.s.action2 - I'd like to hear the design reasoning behind the
Messages changes. I liked the use of Maps in the XWork design as it
made it easier to work with. On the other hand, encapsulating message
operations in the Messages object does reduce the number of
message-handling methods required. Perhaps Messages could extend Map?
Also, I agree we should continue to support plain Messages, as not
all apps need to be localized.
- Passing in keys vs. actual messages - I think always passing in keys
is one thing Struts got right. Even if you only support one language,
abstracting messages out of your code is still a good practice.
It is generally possible to do both, perhaps through a configuration switch that
controls whether to report errors on missing message keys or to treat them as
the message.
- This design doesn't force inheritance. Notice we don't have
ActionSupport anymore? If users still want to have the implicit
methods, they can statically import them from a support class. The
support class implementation would look up the thread local Request
and delegate to it. I didn't add this yet because I'm not sure if we
really need it.
I agree that we should move away from basically requiring ActionSupport to be
extended, which is why I was wondering about the possibility of moving those
*Aware interfaces over to Request to decorate the Request instance.
- In the old design, messages were scoped to an action which doesn't
work very well when you're chaining and you want to display all the
errors from all the actions. I think we want messages to be scoped to
the request (i.e. spanning multiple actions). We actually use our own
message handling and ignore WebWork's at the moment.
Agreed.
- Regarding your Map comment, we've considered having
Messages.forFields() return a Map>. Would that
work? That would be identical to what WebWork supports today.
I'd like to see it implement Map directly, allowing you to treat it as a simple
Map if your requirements are simple enough. The use of standard collections is
something I'd like to retain from WebWork 2.
I'm not sure I understand the separation of Validatable and
ErrorAware. In particular, Validatable only has a validate() method
that returns void. Is there really a case you want to validate, but
not have errors sent anywhere? I think of the use case of plugging in
a different validation engine like commons-validator, and this
separation makes it harder. Why not return Messages?
I've been thinking Validatable should extend ErrorAware, but I wanted
to see what you guys thought first. I don't like the idea of
validate() return Messages. I never liked the fact that I had to
create an errors object in Struts. I also want to be able to easily
add validation messages from setters (I like doing field level
validation in the setter and cross field validations in validate()).
I think Jason had a good observation here concerning ValidationContext. I like
having a context (or perhaps Request itself) that implements Error/MessageAware
and have that passed around. I agree the user shouldn't be creating this
themselves.
o.a.s.action2.attribute - This is again a feature I'd like to hear the
design reasonings of. I liked the previous use of Maps as they were
easy to test and pass around. Maps can also be extended to provide
the automatic synchonrization feature talked about easily.
This is something I've been kicking around since generics came out.
Now that we have generics, it seems funny to be passing around a
heterogeneously typed map. The new way results in better type safety
and less code. Here are some examples for comparison:
Old way:
public class OldWay implements SessionAware {
static final String FOO_KEY = Foo.class.getName();
Map session;
public void setSession(Map session) {
this.session = session;
}
public String execute() {
Foo foo = (Foo) session.get(FOO_KEY);
if (foo == null) {
foo = new Foo();
session.put(FOO_KEY, foo);
}
foo.doSomething();
return SUCCESS;
}
}
New way:
public class NewWay {
Attribute fooAttribute = new
SessionAttribute(Foo.class.getName()) {
protected Foo initialValue() {
return new Foo();
}
};
public String execute() {
Foo foo = fooAttribute.get();
foo.doSomething();
return SUCCESS;
}
}
Testing is actually easier--it's easier to mock out Attribute than Map.
I also proposed an annotation based approach, but Patrick preferred
the attribute API. Here's how that could work:
public class AnnotationWay {
Foo foo;
// result is stored on session, called after execute() but
before result.
@SessionAttribute
public Foo getFoo() {
if (foo == null) {
this.foo = new Foo();
Re: [action2] Public API first draft
I'm not quite ready for a vote on the API, because I think what we'd be voting on is still under active discussion. We could decide under what criteria we will be evaluating these API changes. I propose they be: 1. Can we get a GA release out by August? 2. Will at least WebWork 2 apps have an easy (as in hours, not days) transition? I realize that might mean we have to put of some more drastic changes to the next release, and it may result in some compromises, but in the end, I think it is more important to get a usable, timely release out to our users, and ensure their migration will be smooth. Migration, in particular, is a key concern because it is an important advantage we could hold, as other frameworks tend to require a complete redesign and re-education of developers. I want Struts Action Framework 2 to be seen as easy and powerful, not just from a feature standpoint, but also migration, education, and "conceptual space" one. This doesn't preclude making sweeping API changes that the average users either won't see or aren't noticed since the old objects/interfaces still work correctly. The question then becomes one of energy available to offset new changes with proper backwards-compatibility support. Struts users have been looking for a smooth transition to next-generation technologies for some time now, and I think we've let them down. It is time to deliver. Don Gabe wrote: I agree both that this is the core decision that has to be made now and that we should push some of this stuff into XWork. I won't vote though, because I've learned we're discussing not voting :-D - Original Message From: Jason Carreira <[EMAIL PROTECTED]> To: dev@struts.apache.org Sent: Thursday, May 4, 2006 4:52:48 PM Subject: Re: [action2] Public API first draft I think this is the core decision that needs to be made right now. I'm not sure which way I'm leaning on this, but we need to pick a direction. If we're going to redesign the API and get things right, then lets decide to do that and re-open WebWork to bug fixes and more releases in the meantime. Either way I'd like to push some of this stuff into XWork, not just leave it in SAF2. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29317&messageID=57075#57075 - 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]
[action2] Leveraging known constructs (was Public API first draft)
Don Brown wrote:
re-education of developers. I want Struts Action Framework 2 to be seen
as easy and powerful, not just from a feature standpoint, but also
migration, education, and "conceptual space" one.
I was talking to Eric on the ww dev chat, and he brought up a good point that
resonated with me: we should be leveraging more known, common constructs in
developing this API.
For example, the Messages object, rather than leverage the familiar Log
interface we all use every day. Messages are collected, much like logging
messages and their levels are similar. Therefore, we'd have:
msgs.info("some.key");
msgs.warn("some.warn.key");
msgs.error("some.error.key");
We'd still keep the four different versions of the add function to handle field
errors and parameters. Furthermore, Messages could implement Collection and
Map, allowing it to be treated easily by existing tags and code built to handle
these common constructs.
Yes, this adds more methods but the value to the developer, I think, is worth
it. I'd rather error on the side of making our job harder than require more
work and learning on the part of the end developer. Martin Fowler calls it a
Humane Interface pattern [1], and while I don't completely agree with that
pattern (78 methods for a List?!), I do think we should be designing from the
standpoint of the end developer, not from the framework developer. Let's make
Struts Action 2 powerful, easy, and even _intuitive_.
Don
[1] http://www.martinfowler.com/bliki/HumaneInterface.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Leveraging known constructs (was Public API first draft)
I don't think it's a question of making things easier for the user or not
vs. our effort.
Are you saying you want arbitrary levels for messages (a la JSF)?
Bob
On 5/4/06, Don Brown <[EMAIL PROTECTED]> wrote:
Don Brown wrote:
> re-education of developers. I want Struts Action Framework 2 to be seen
> as easy and powerful, not just from a feature standpoint, but also
> migration, education, and "conceptual space" one.
I was talking to Eric on the ww dev chat, and he brought up a good point
that
resonated with me: we should be leveraging more known, common constructs
in
developing this API.
For example, the Messages object, rather than leverage the familiar Log
interface we all use every day. Messages are collected, much like logging
messages and their levels are similar. Therefore, we'd have:
msgs.info("some.key");
msgs.warn("some.warn.key");
msgs.error("some.error.key");
We'd still keep the four different versions of the add function to handle
field
errors and parameters. Furthermore, Messages could implement Collection
and
Map, allowing it to be treated easily by existing tags and code built to
handle
these common constructs.
Yes, this adds more methods but the value to the developer, I think, is
worth
it. I'd rather error on the side of making our job harder than require
more
work and learning on the part of the end developer. Martin Fowler calls
it a
Humane Interface pattern [1], and while I don't completely agree with that
pattern (78 methods for a List?!), I do think we should be designing from
the
standpoint of the end developer, not from the framework developer. Let's
make
Struts Action 2 powerful, easy, and even _intuitive_.
Don
[1] http://www.martinfowler.com/bliki/HumaneInterface.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
TestGen4Web (was: Re: svn commit: r399762 - in /struts/action/trunk/integration/tg4w: ...)
On 5/4/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: I still need to provide detailed instructions (ya, it's on my todo list :) ), but basically, just do this: - build and deploy the struts-blank.war sample app ~/svn/struts/current/action/apps/blank $ mvn package cargo:start (This will package and deploy struts-blank on localhost:8080. It assumes you have run 'mvn install' once from the top to buildthe jars, and that cargo.tomcat5x.home is set. See the StrutsMaintenanceMaven wiki page for more info.) Then in another console window: - cd to this dir - $mvn test I tried... ~/svn/struts/current/action/integration/tg4w $ mvn test ... [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) com.spikesource:testgen4web-translator:jar:0.3-SNAPSHOT Fix: Add your m2 repo in / in addition to the existing . (I tried it without the but I got a different error.) You'll see the dependencies downloaded and the test generated and run. You'll also see the output as the test proceeds (assertions, etc), which is part of the underlying TestGen4Web sysouts. I see "skip testing for title!" in the output [1]. It doesn't appear to be checking-- I changed the blank-verify-welcome.xml file to the wrong title, and the test still passes. Thanks. :) [1] http://wiki.wsmoak.net/cgi-bin/wiki.pl?TestGen4Web/Output -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why vote twice for a release quality?
I think the (B) vote is a copy-and-paste error. The form element was introduced between 1.25 and 1.26, but its never been used. The (B) lists are tasks that we only need to do after the quality is determined to be GA, so the one-and-only vote comes in the middle. -Ted. On 5/4/06, Don Brown <[EMAIL PROTECTED]> wrote: I'm preparing to draw the Struts Action 1.3.2 release quality vote to a close, but as I look at the release plan, I see it has us voting twice on the same release for the same quality vote (vote a and b). Why is this? Seems to me one vote should be plenty. Don - 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: [VOTE] Release the struts-parent pom v2
+1 On 5/3/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: We need to release version 2 of the struts-parent pom: * http://svn.apache.org/repos/asf/struts/maven/trunk/pom/pom.xml This is the parent pom from which struts-action-parent inherits, and it needs to be released prior to the Struts Action 1.3.3 test build. Changes since v1 include: - Addition of the issues and commits mailing lists - New PMC members Sean and Greg Once again I need to shorten the vote period in order to get this published in advance of the test build. Sorry, I'll start earlier next time. :) The vote will close in 48 hours, on Friday at 8:30 pm PST (GMT -7). Here's my +1. -- Wendy - 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] Leveraging known constructs (was Public API first draft)
The new Messages API could easily be mapped onto an implementation
similar to that of Log4J. Why not embrace that idea and utilize
familiar methods to provide access.
such as...
msgs.info("some.key");
msgs.warn("some.warn.key");
msgs.error("some.error.key");
It does increase the number of methods but the argument is that the
familiarity outweighs the effort of adding those methods. By default
it only provides a small set of fixed levels, however custom levels
should be easy to implement. I would even argue having a limited set
of built in levels actually makes things easier for new developers.
There are a few APIs that are known to almost all developers. By
embracing a similar API a sense of familiarity is provided that should
ease adoption and understanding. That's my rational at least and it
usually serves me well.
Cheers,
Eric
On 5/4/06, Bob Lee <[EMAIL PROTECTED]> wrote:
I don't think it's a question of making things easier for the user or not
vs. our effort.
Are you saying you want arbitrary levels for messages (a la JSF)?
Bob
On 5/4/06, Don Brown <[EMAIL PROTECTED]> wrote:
> Don Brown wrote:
> > re-education of developers. I want Struts Action Framework 2 to be seen
> > as easy and powerful, not just from a feature standpoint, but also
> > migration, education, and "conceptual space" one.
>
> I was talking to Eric on the ww dev chat, and he brought up a good point
that
> resonated with me: we should be leveraging more known, common constructs
in
> developing this API.
>
> For example, the Messages object, rather than leverage the familiar Log
> interface we all use every day. Messages are collected, much like logging
> messages and their levels are similar. Therefore, we'd have:
>
> msgs.info("some.key");
> msgs.warn("some.warn.key");
> msgs.error("some.error.key");
>
> We'd still keep the four different versions of the add function to handle
field
> errors and parameters. Furthermore, Messages could implement Collection
and
> Map, allowing it to be treated easily by existing tags and code built to
handle
> these common constructs.
>
> Yes, this adds more methods but the value to the developer, I think, is
worth
> it. I'd rather error on the side of making our job harder than require
more
> work and learning on the part of the end developer. Martin Fowler calls
it a
> Humane Interface pattern [1], and while I don't completely agree with that
> pattern (78 methods for a List?!), I do think we should be designing from
the
> standpoint of the end developer, not from the framework developer. Let's
make
> Struts Action 2 powerful, easy, and even _intuitive_.
>
> Don
>
> [1] http://www.martinfowler.com/bliki/HumaneInterface.html
>
> -
> 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: TestGen4Web (was: Re: svn commit: r399762 - in /struts/action/trunk/integration/tg4w: ...)
Looks as though the velocity template isn't quite finished, so I'm going to help out the friendly folks at spikesource and make the changes myself. I'll post back with an update as soon as its ready. Oh, and thanks for trying this. -- James Mitchell On May 4, 2006, at 8:00 PM, Wendy Smoak wrote: On 5/4/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: I still need to provide detailed instructions (ya, it's on my todo list :) ), but basically, just do this: - build and deploy the struts-blank.war sample app ~/svn/struts/current/action/apps/blank $ mvn package cargo:start (This will package and deploy struts-blank on localhost:8080. It assumes you have run 'mvn install' once from the top to buildthe jars, and that cargo.tomcat5x.home is set. See the StrutsMaintenanceMaven wiki page for more info.) Then in another console window: - cd to this dir - $mvn test I tried... ~/svn/struts/current/action/integration/tg4w $ mvn test ... [ERROR] BUILD ERROR [INFO] -- -- [INFO] Failed to resolve artifact. Missing: -- 1) com.spikesource:testgen4web-translator:jar:0.3-SNAPSHOT Fix: Add your m2 repo in / in addition to the existing . (I tried it without the but I got a different error.) You'll see the dependencies downloaded and the test generated and run. You'll also see the output as the test proceeds (assertions, etc), which is part of the underlying TestGen4Web sysouts. I see "skip testing for title!" in the output [1]. It doesn't appear to be checking-- I changed the blank-verify-welcome.xml file to the wrong title, and the test still passes. Thanks. :) [1] http://wiki.wsmoak.net/cgi-bin/wiki.pl?TestGen4Web/Output -- Wendy - 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] Leveraging known constructs (was Public API first draft)
Here is what I'm talking about:
http://people.apache.org/~mrdon/action2-api-don/org/apache/struts/action2/Messages.html
This approach has the advantages of closely following the familiar Log
interface, and by leveraging the List and Map interfaces, makes it easy
to manipulate and access data from any tag or expression language that
supports collections. On the other hand, it doesn't support arbitrary
message types, and would require a number of methods in an
implementation class. This is what I meant when I said this approach
favors end user convenience over framework developer maintenance. I'm
not saying the List and Map interfaces are better designed than what we
could come up with here, but they are what developers know and feel
confortable with, so perhaps we should leverage that.
Personally, I've never had a need for any other types of messages other
than info, warn, and error, but I could be in the minority here.
Don
Bob Lee wrote:
I don't think it's a question of making things easier for the user or not
vs. our effort.
Are you saying you want arbitrary levels for messages (a la JSF)?
Bob
On 5/4/06, Don Brown <[EMAIL PROTECTED]> wrote:
Don Brown wrote:
> re-education of developers. I want Struts Action Framework 2 to be
seen
> as easy and powerful, not just from a feature standpoint, but also
> migration, education, and "conceptual space" one.
I was talking to Eric on the ww dev chat, and he brought up a good point
that
resonated with me: we should be leveraging more known, common constructs
in
developing this API.
For example, the Messages object, rather than leverage the familiar Log
interface we all use every day. Messages are collected, much like
logging
messages and their levels are similar. Therefore, we'd have:
msgs.info("some.key");
msgs.warn("some.warn.key");
msgs.error("some.error.key");
We'd still keep the four different versions of the add function to
handle
field
errors and parameters. Furthermore, Messages could implement Collection
and
Map, allowing it to be treated easily by existing tags and code built to
handle
these common constructs.
Yes, this adds more methods but the value to the developer, I think, is
worth
it. I'd rather error on the side of making our job harder than require
more
work and learning on the part of the end developer. Martin Fowler calls
it a
Humane Interface pattern [1], and while I don't completely agree with
that
pattern (78 methods for a List?!), I do think we should be designing
from
the
standpoint of the end developer, not from the framework developer.
Let's
make
Struts Action 2 powerful, easy, and even _intuitive_.
Don
[1] http://www.martinfowler.com/bliki/HumaneInterface.html
-
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]
