Re: [OS-webwork] Rethink
matt baldree wrote: Personally, I like these ideas. I think this design would lead people to cleaner solutions. I think it is time to make some decisions. I think Rickard should architect XWork. It would then be up to him to assign/delegate work on different modules, etc. I'm not convinced the current direction will lead to the best outcome. Rickard has established himself in past frameworks, application servers and his new portal product to earn the right to architect XWork. Besides, he mainly wrote WW. I may be wrong, but I don't remember an e-mail asking if he wanted to architect XWork or what role he wanted to play. I think this is a mistake. I think we should at least offer him the opportunity to architect XWork. I think his ideas have solidified and he is ready to right some code :). So, any dissenters? I'm not interested in getting XWork out the door quickly but when it does come out, I want it to be GREAT. No dissenters then? :-) I must admit that at first I was reluctant to the idea, since I already have so many irons in the fire, with the portal product and AOP framework coming along. However, since XWork could borrow so much from the AOP stuff, it's really not that much work, at least for the core (or so it seems). We (my company) are also greatly dependent on XWork being as good as it can be, so that's a huge motivational factor here. I would hence gladly take on this role, at least when it comes to shaping the core of it. Once the dust settles somewhat, and there will be a lot of dust initially, I think there will be great opportunities for others to do major contributions to it, especially when it comes to creating standard interceptors that can be shipped with the framework. Alternative dispatchers is also a very important part. So, if everyone is ok with me as (initially) main architect, I'll get to it. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Rethink
Currently, there's no way to keep people from executing your actions without creating a separate J2EE declarative security entry for each action (and each alias, etc). This is, IMHO, a HUGE drawback. ...or just a servlet filter. Anders Hovmöller [EMAIL PROTECTED] http://boxed.killingar.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Rethink
Yep - +1 from me, but I think Patrick should also have a major role in contributing, he has done a lot of the initial Xwork thinking and I think his knowledge of OGNL etc would be valuable. -mike On 2/1/03 9:06 PM, Rickard Öberg ([EMAIL PROTECTED]) penned the words: matt baldree wrote: Personally, I like these ideas. I think this design would lead people to cleaner solutions. I think it is time to make some decisions. I think Rickard should architect XWork. It would then be up to him to assign/delegate work on different modules, etc. I'm not convinced the current direction will lead to the best outcome. Rickard has established himself in past frameworks, application servers and his new portal product to earn the right to architect XWork. Besides, he mainly wrote WW. I may be wrong, but I don't remember an e-mail asking if he wanted to architect XWork or what role he wanted to play. I think this is a mistake. I think we should at least offer him the opportunity to architect XWork. I think his ideas have solidified and he is ready to right some code :). So, any dissenters? I'm not interested in getting XWork out the door quickly but when it does come out, I want it to be GREAT. No dissenters then? :-) I must admit that at first I was reluctant to the idea, since I already have so many irons in the fire, with the portal product and AOP framework coming along. However, since XWork could borrow so much from the AOP stuff, it's really not that much work, at least for the core (or so it seems). We (my company) are also greatly dependent on XWork being as good as it can be, so that's a huge motivational factor here. I would hence gladly take on this role, at least when it comes to shaping the core of it. Once the dust settles somewhat, and there will be a lot of dust initially, I think there will be great opportunities for others to do major contributions to it, especially when it comes to creating standard interceptors that can be shipped with the framework. Alternative dispatchers is also a very important part. So, if everyone is ok with me as (initially) main architect, I'll get to it. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Rethink
Agree. I think there is obvious areas certain people can help. -Matt - Original Message - From: Mike Cannon-Brookes [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Sent: Thursday, January 02, 2003 7:30 AM Subject: Re: [OS-webwork] Rethink Yep - +1 from me, but I think Patrick should also have a major role in contributing, he has done a lot of the initial Xwork thinking and I think his knowledge of OGNL etc would be valuable. -mike On 2/1/03 9:06 PM, Rickard Öberg ([EMAIL PROTECTED]) penned the words: matt baldree wrote: Personally, I like these ideas. I think this design would lead people to cleaner solutions. I think it is time to make some decisions. I think Rickard should architect XWork. It would then be up to him to assign/delegate work on different modules, etc. I'm not convinced the current direction will lead to the best outcome. Rickard has established himself in past frameworks, application servers and his new portal product to earn the right to architect XWork. Besides, he mainly wrote WW. I may be wrong, but I don't remember an e-mail asking if he wanted to architect XWork or what role he wanted to play. I think this is a mistake. I think we should at least offer him the opportunity to architect XWork. I think his ideas have solidified and he is ready to right some code :). So, any dissenters? I'm not interested in getting XWork out the door quickly but when it does come out, I want it to be GREAT. No dissenters then? :-) I must admit that at first I was reluctant to the idea, since I already have so many irons in the fire, with the portal product and AOP framework coming along. However, since XWork could borrow so much from the AOP stuff, it's really not that much work, at least for the core (or so it seems). We (my company) are also greatly dependent on XWork being as good as it can be, so that's a huge motivational factor here. I would hence gladly take on this role, at least when it comes to shaping the core of it. Once the dust settles somewhat, and there will be a lot of dust initially, I think there will be great opportunities for others to do major contributions to it, especially when it comes to creating standard interceptors that can be shipped with the framework. Alternative dispatchers is also a very important part. So, if everyone is ok with me as (initially) main architect, I'll get to it. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Rethink
-Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Here are some that I can think of: * Try to avoid .action URL's * Allow for multiple read-actions to be on the same page (HMVC) * Allow for multiple forms to be on the same page, and be developed independently (the portal case). This essentially means that parameters need to be prefixed so that they don't clash. * Allow write-actions to be performed before a page starts rendering, but then make the result of that action available DURING rendering. * Minimize coupling to servlet environment. XWork will probably still be a framework that is used mostly for web stuff, but it must be possible to use it in a non-servlet environment too. Having multiple dispatchers from the start is a great way to ensure this. * Allow sharing of view code between different views * Make it trivial to implement Portlets (JSR 168) using XWork. This is a personal pet peeve, but I think you'll love it once the Portlet API solidifies later this year. It's a great thing I think. /Rickard Some of the lifecycle and multi-component stuff here sounds a lot like Java Server Faces. I just finished reading the two articles on JSF at onJava.com: http://www.javaworld.com/javaworld/jw-11-2002/jw-1129-jsf.html http://www.javaworld.com/javaworld/jw-12-2002/jw-1227-jsf2.html I must say, I'm underwhelmed in a lot of areas, especially with how much processing has to be done for every request and the heavy dependency on JSP and the web, but the potential for real tool support is very appealing. What are people's thoughts on supporting JSF with Webwork, perhaps with a different Dispatcher? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Rethink
-Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 02, 2003 5:37 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Rethink Patrick Lightbody wrote: Great! So we can expect a finished product by Friday? :) Friday? *yawn* :-) Glad to have you on board with this. Of course, I'll be around to help in any way possible -- just gimme a holler. Will do. I'm afraid I'm gonna thrash around in the current sandbox code quite a lot. One thing though: I desperately need to know if chaining needs to be possible given the concept of interceptors. I want to see if there are easier ways to deal with the usecases where chaining is used currently. Yes, For our needs, chaining is very very helpful. More on this below... Also, I want to establish some design goals. IMHO the end result will be better with more strict requirements. Here are some that I can think of: * Try to avoid .action URL's * Allow for multiple read-actions to be on the same page (HMVC) * Allow for multiple forms to be on the same page, and be developed independently (the portal case). This essentially means that parameters need to be prefixed so that they don't clash. * Allow write-actions to be performed before a page starts rendering, but then make the result of that action available DURING rendering. * Minimize coupling to servlet environment. XWork will probably still be a framework that is used mostly for web stuff, but it must be possible to use it in a non-servlet environment too. Having multiple dispatchers from the start is a great way to ensure this. * Allow sharing of view code between different views * Make it trivial to implement Portlets (JSR 168) using XWork. This is a personal pet peeve, but I think you'll love it once the Portlet API solidifies later this year. It's a great thing I think. /Rickard Some goals I would hope for: * declarative security friendly URLs and the ability to protect your actions from being called. * multiple configuration files, to improve multi-user version control concurrency - In the current (proprietary) framework we use, this is done by having one main configuration file which maps certain paths to certain config files. These sub config files define the request handlers (like actions) and response handlers (like views). The nice thing about this is the way chaining is handled. Below a certain path, which is mapped to a sub-config file, every path segment is treated as a reference to a handler. So, for instance, if we have a sub-section with a separate config file mapped to /foo, this url: /foo/handler1/handler2/handler3 Would look up and invoke handler1, then handler2, then handler3 in that order, and return the response handler (view) associated with the final request handler (action), unless an error is encountered. This allows for very fine grained reusable application pieces, which can be put together dynamically by creating a URL. Unfortunately, the current framework doesn't have the concept of the value stack, and does everything by binding beans into the request. Handlers don't have properties like Actions, but are more stateless and just use the request parameters directly. Jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Rethink
Jason Carreira wrote: Some goals I would hope for: * declarative security friendly URLs and the ability to protect your actions from being called. See the Action invocation post. .action URL's should go away with that. * multiple configuration files, to improve multi-user version control concurrency See the Action configuration XML, and particularly the package idea. With XML entities you're there. - In the current (proprietary) framework we use, this is done by having one main configuration file which maps certain paths to certain config files. These sub config files define the request handlers (like actions) and response handlers (like views). The nice thing about this is the way chaining is handled. Below a certain path, which is mapped to a sub-config file, every path segment is treated as a reference to a handler. So, for instance, if we have a sub-section with a separate config file mapped to /foo, this url: /foo/handler1/handler2/handler3 Would look up and invoke handler1, then handler2, then handler3 in that order, and return the response handler (view) associated with the final request handler (action), unless an error is encountered. Which is bad because you're displaying the guts of your application to the user. URL's of that kind will likely be shortlived. No good. This allows for very fine grained reusable application pieces, which can be put together dynamically by creating a URL. You'll get the same with actions calling actions (easy with the new API) and action interceptors. Except it's all under the covers. Unfortunately, the current framework doesn't have the concept of the value stack, and does everything by binding beans into the request. Handlers don't have properties like Actions, but are more stateless and just use the request parameters directly. Ok, I see. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Rethink
Rickard, I don't know if interceptors will cover chaining needs entirely, but why not just start hacking away in the sandbox and we'll go from there. -Pat - Original Message - From: Rickard Öberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 02, 2003 2:36 AM Subject: Re: [OS-webwork] Rethink Patrick Lightbody wrote: Great! So we can expect a finished product by Friday? :) Friday? *yawn* :-) Glad to have you on board with this. Of course, I'll be around to help in any way possible -- just gimme a holler. Will do. I'm afraid I'm gonna thrash around in the current sandbox code quite a lot. One thing though: I desperately need to know if chaining needs to be possible given the concept of interceptors. I want to see if there are easier ways to deal with the usecases where chaining is used currently. Also, I want to establish some design goals. IMHO the end result will be better with more strict requirements. Here are some that I can think of: * Try to avoid .action URL's * Allow for multiple read-actions to be on the same page (HMVC) * Allow for multiple forms to be on the same page, and be developed independently (the portal case). This essentially means that parameters need to be prefixed so that they don't clash. * Allow write-actions to be performed before a page starts rendering, but then make the result of that action available DURING rendering. * Minimize coupling to servlet environment. XWork will probably still be a framework that is used mostly for web stuff, but it must be possible to use it in a non-servlet environment too. Having multiple dispatchers from the start is a great way to ensure this. * Allow sharing of view code between different views * Make it trivial to implement Portlets (JSR 168) using XWork. This is a personal pet peeve, but I think you'll love it once the Portlet API solidifies later this year. It's a great thing I think. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Rethink
Chris Nokleberg wrote: On Tue, Dec 31, 2002 at 10:21:21AM +0100, Rickard Öberg wrote: Patrick Lightbody wrote: Yeah, doesn't yet, but the plan is to add that in soon. Tonight I'll make the code quicker and then start incorporating Rickards ideas. Well, since this is looking more and more like a lightweight version of my AOP framework I can do the interceptor/XML fixes myself, if that's ok with you. I think it would be more useful if instead of applying directly to actions, the filters/interceptors applied to paths (URLs). The paths could support wildcards, either Servlet-style or a more complete regexp style. e.g. define secure = persist, security, execute define open = standard - security map /* = open map /admin/* = secure (but probably in xml) There would need to be some thought about how to combine stacks of interceptors, path matching precedence, etc. This is probably best done in conjuction with nailing down actions to specific paths. The problem is that people will then start naming their pages in order to make it easy to apply filters. And that's bad. URL's should not reveal the underlying technology, and should be as long-lived as possible. Also imagine if you have a page that is initially unsecured, but after a while you see that it needs to be secured. Will you then add its path to the configuration or move it to /secure? Probably the latter, and you then broke all bookmarks to it. Nah, there's gotta be a better way. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Rethink
Jason Carreira wrote: Along this line, I've mentioned before that one of the top requirements I've got for a framework, and we're hopefully going to be switching to a new (better) framework in the next few months, is the ability to use J2EE declarative security to secure paths. This means that the way actions are invoked needs to be rethought. Currently, there's no way to keep people from executing your actions without creating a separate J2EE declarative security entry for each action (and each alias, etc). This is, IMHO, a HUGE drawback. I agree. There are a couple of things one can do here. First of all, read-only actions should (IMHO) be invoked from WITHIN a page either using an action tag (in JSP) or by using an include. That way the URL doesn't reveal that WebWork is being used. The ServletDispatcher could then be changed so that it only allows invocation through includes. This alone would make a lot of security issues go away. Then the issue of read/write actions remain, which usually is of the form execute action, redirect to page depending on result. Here it might be interesting to look at the new Portlet API which does something like this: when a page is generated URL's are created and associated with actions (see http://www7b.boulder.ibm.com/wsdd/zones/portal/portlet/4.1api/org/apache/jetspeed/portlet/PortletURI.html). When the submit button of a form is clicked and the URL for the form has been associated with an action that action is then invoked before rendering the page. In this case it is thus the framework that triggers the execution of the read/write action. It's not possible to execute just by knowing a URL. This in itself makes it easier to ensure that code that does things is not executed out of context or insecurely. Since I'm personally ONLY going to be using WebWork/XWork through portlets it'd be neat if XWork right from the start conformed to this pattern. :-) Unfortunately the Portlet API draft has not been released yet due to license issues (BIG ANNOYED *SIGH* GOES HERE), but hopefully it'll be out soonish. And on the component note IMHO Portlets is the right level of abstraction of components. I'd rather see XWork making it simple to do portlets than trying to do our own packaging structure to do (basically) the same thing. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Rethink
Patrick Lightbody wrote: I can apply some real-world examples here: I'm in a screen that is updating document metadata, and the form submits to UpdateMetadata.action. But UpdateMetadata.action is actually an alias for a complex chain: ValidateMetadata - BeginTx - StoreMetadata - CommitTx - StoreMetadataInHtmlFiles - LoadMetadata - showmetadata.jsp Well, that could then probably be rewritten as: ValidateMetadataProxy - TxProxy - StoreMetadataInHtmlFilesProxy - StoreMetadata action where SUCCESS = showmetadata.jsp and the JSP has an action tag pointing to LoadMetadata. Much nicer. Less code. Are there any other cases where the side-effects *should be* real actions, or could all of those be rewritten with action proxies? /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Rethink
By all means, go for it! - Original Message - From: Rickard Öberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 31, 2002 1:21 AM Subject: Re: [OS-webwork] Rethink Patrick Lightbody wrote: Yeah, doesn't yet, but the plan is to add that in soon. Tonight I'll make the code quicker and then start incorporating Rickards ideas. Well, since this is looking more and more like a lightweight version of my AOP framework I can do the interceptor/XML fixes myself, if that's ok with you. /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Rethink
On Tue, Dec 31, 2002 at 10:21:21AM +0100, Rickard Öberg wrote: Patrick Lightbody wrote: Yeah, doesn't yet, but the plan is to add that in soon. Tonight I'll make the code quicker and then start incorporating Rickards ideas. Well, since this is looking more and more like a lightweight version of my AOP framework I can do the interceptor/XML fixes myself, if that's ok with you. I think it would be more useful if instead of applying directly to actions, the filters/interceptors applied to paths (URLs). The paths could support wildcards, either Servlet-style or a more complete regexp style. e.g. define secure = persist, security, execute define open = standard - security map /* = open map /admin/* = secure (but probably in xml) There would need to be some thought about how to combine stacks of interceptors, path matching precedence, etc. This is probably best done in conjuction with nailing down actions to specific paths. -Chris --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Rethink
Along this line, I've mentioned before that one of the top requirements I've got for a framework, and we're hopefully going to be switching to a new (better) framework in the next few months, is the ability to use J2EE declarative security to secure paths. This means that the way actions are invoked needs to be rethought. Currently, there's no way to keep people from executing your actions without creating a separate J2EE declarative security entry for each action (and each alias, etc). This is, IMHO, a HUGE drawback. Jason -Original Message- From: Chris Nokleberg [mailto:[EMAIL PROTECTED]] I think it would be more useful if instead of applying directly to actions, the filters/interceptors applied to paths (URLs). The paths could support wildcards, either Servlet-style or a more complete regexp style. e.g. define secure = persist, security, execute define open = standard - security map /* = open map /admin/* = secure (but probably in xml) There would need to be some thought about how to combine stacks of interceptors, path matching precedence, etc. This is probably best done in conjuction with nailing down actions to specific paths. -Chris --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Rethink
On Mon, 30 Dec 2002, [UTF-8] Rickard Öberg wrote: Joseph Ottinger wrote: Well, note the quotes I used. Correctness can be taken a lot of ways. What I was referring to was buzzword-compatible correctness, where the comp sci grads are happy applying all of their new-found knowledge in ways that end up making the product less usable. Between usability and correctness, I'll take usability. I see. My interpretation of correctness contains a high degree of usability :-) Think property editors. Correct. Very correct. Usable, but unused. This is sort of why I dislike the current xwork.xml structure - it's correct but unusable. (Well, it's usable, but *I* wouldn't want to use it.) Agree completely. Whoever came up with that should be run out on a rail! :) :) :) As far as the validation... as long as the definition is clear, I'm happy. Ok, good. I'd also like to add a request for formal scope for XWork (and webwork, too, for that matter, although it's too late.) A scope document would correct a lot of the issues people have, and reduce the learning curve, as well. It would also help you determine what was and was not within the domain of XWork - for example, a scope document woudl specify that the model was out of scope whereas a bridge to the data model was not (i.e., Xwork will not provide connection pooling for you, nor a persistence layer at all, although your specific dispatcher may provide mechanisms in which you can persist changes made programmatically.) - Joseph B. Ottinger [EMAIL PROTECTED] http://enigmastation.comIT Consultant --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Rethink
* Chaining. IMHO this needs a big rethink, and most of all we need to check: what are the usecases to be implemented. What would be an alternative way of doing chaining? Your example where the chaining is done in code and is specified by the action itself is just not acceptable for me, as it would fuck up a lot of the clean design I currently achieve with aliasing and chaining in WW. Anders Hovmöller [EMAIL PROTECTED] http://boxed.killingar.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Rethink
boxed wrote: * Chaining. IMHO this needs a big rethink, and most of all we need to check: what are the usecases to be implemented. What would be an alternative way of doing chaining? Your example where the chaining is done in code and is specified by the action itself is just not acceptable for me, What example? /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Rethink
Packaging I would define as the ability to create 'components' consisting of WW actions, configuration for those actions and the views. With Velocity (loaded from classpath) views, abstracted common view code and componentised actions.xml, what else do we need to do? Mike is bringing up a very important issue imho. It should be possible to create 'components' as he describes. We'll end up having probably a meta-inf/component.xml file which acts as the glue for view/action/templates/blabla aspects of a component. And then of course separate action.xml/view.xml/blabla.xml for each aspect. I think it's good, it looks like Tapestry's jwc file which really acts like a palette where you mix different pluggable components to create new components. This way you can create a reusable shopping component which has all the actions (with validation/security/persistence aspects of each configurable via the xml file) and view and other aspects of the components configured properly in the xml file. As Mike said this is where Tapestry really shines. Tapestry's main points are 'components' and the span/-based approach for the view part. What WW is really good at is the action/controller part. So with Rickard's proposal we'll have even a better configurable/pluggable/reusable architecture for the actions. Then add 'components' to the mix and you get to another higher level of reusability. That'll be kick ass! Ara. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Rethink
My favourite usecase is the show-edit-update-show usecase. Which means having the need to pass the primary key of the object updated to the action show which is the view of the Update action. Views.proptiers whould look like that: Show.success=show.xslt Update.success=Show.action I would personally prefer that Update redirects to Show instead, because otherwise a refresh will do the update again. The browser location should never point to an action that does things. Yes, you're right, but the point is that one need to pass some data (the key) to the redirect action. There two ways, doing it automatically or explicitely. Philipp, I'm fairlu sure Xwork does this already (and if not yet, it certainly will do it). Update.success=Show.action?id=$id where $id is pulled from Update.getId() -mike --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Rethink
Yeah, doesn't yet, but the plan is to add that in soon. Tonight I'll make the code quicker and then start incorporating Rickards ideas. -Pat - Original Message - From: Mike Cannon-Brookes [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Sent: Monday, December 30, 2002 3:07 PM Subject: Re: [OS-webwork] Rethink My favourite usecase is the show-edit-update-show usecase. Which means having the need to pass the primary key of the object updated to the action show which is the view of the Update action. Views.proptiers whould look like that: Show.success=show.xslt Update.success=Show.action I would personally prefer that Update redirects to Show instead, because otherwise a refresh will do the update again. The browser location should never point to an action that does things. Yes, you're right, but the point is that one need to pass some data (the key) to the redirect action. There two ways, doing it automatically or explicitely. Philipp, I'm fairlu sure Xwork does this already (and if not yet, it certainly will do it). Update.success=Show.action?id=$id where $id is pulled from Update.getId() -mike --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
