Re: [OS-webwork] XWork: core concepts
Rickard, This has been brought up before, I think, but I'm not sure it was answered well enough. What about people that want to use XML, Velocity, Jasper Reports, or some other view technology? You are using JSP to include the actions, but how would you do that with XML, for example? Blake Day On Fri, 2003-01-10 at 20:59, Rickard Öberg wrote: All, Since quite a few of you disagreed with my resignation as XWork architect, I've given some thought to how it would be possible to merge my requirements with those that you have. It might be possible to do it, and if so I would reconsider re-starting my work on XWork. I'd like to begin with defining the core concepts that XWork would have, and also briefly list my requirements, and see what your thoughts on them are. Good to have you back The core concepts that I think must be included are the following: * Actions. These are the application implementations (generic or specific) that together define the behaviour of the application. No news here. * Interceptors. These are cross-cutting concerns that apply to several actions, and which may modify the behaviour of it, produce some side-effect to the execution of the Action, or modify the input or output of the Action. * Components. This is a new concept for WebWork. Instead of just having a bunch of non-related Action's, one would bundle some of them together into a Component. An Action may be part of several Components though. The main feature of a Component is to function as a state machine which determine what Action to execute during a page rendering. * Packages. Also a new concept. There are usually two approaches to configuration: coarse-grained or fine-grained. In the coarse-grained style a setting applies to EVERYTHING in the app. In the fine-grained style each part needs to be individually configured. The first focus on ease-of-use and the latter on flexibility. Packages allow for something in between. An Action, Interceptor or Component can be defined in a Package and can easily refer to one another within that package. By having hierarchical packages can easily refer to definitions in other Packages. For example, we would most likely define a number of Actions, Interceptors and possible Components that are in a default Package, which user Packages would then depend on. However, user Packages could then override any such definition made higher up. This gives the ease-of-use of a coarse-grained configuration together with the total control and flexibility of a fine-grained configuration, while still providing reasonably clear semantics. Are views a core concept ? The other thing we might want to address is whether or not XWork will be somewhat seperated at the core from the web. These are the core concepts that I can think of. Now, for my own portlet-ish needs (which I hope will be more common for others too in the future) the following applies: * Actions and Components, and their resulting views, are ALWAYS called through a servlet include. This means that the URL in a browser NEVER reveals that XWork is used. For example, an admin app would consist of an admin.jsp which includes the Actions/Components needed for that app. Not only does that make it easy to extend the admin app later on with more portlets, it also makes it possible (for those who are so inclined) to use J2EE declarative security very easily. Plus bookmarks are human-friendly. This means that the dispatcher would explicitly disallow Action invocation that are NOT a result of an include. This too adds some extra security, since only actions that YOU decide should be called are actually callable. Plus, your actions can decide much better in what order they are called, depending on your app requirements. The actual include would still be using the .action extension though. Sure but I'm not sure how this relates to calling views outside a servlet environment ? * For many simple portlets an include of a .action is fine. For complex portlets that require a state machine this is not ok. Instead, what one usually wants is to include a component that then delegates to some action depending on the *state* of some automata. This is similar to how the CardPane works in WebWork. Essentially, XWork would include this kind of state machine as a built-in concept instead of as an add-on like CardPane, since this is such an important and common case. It needs to be as simple and flexible as is possible. When a component renders its view it also creates URL's that define what the possible next states are. This means that the URL's in the generated HTML are shortlived (i.e. after one of the URL's have been clicked they are all invalid), which also means that it will be impossible to have a double form submit. After the first submit the URL will be invalid, so clicking again will not lead to a re-execution of the action.
Re: [OS-webwork] XWork: core concepts
Correct me if I'm wrong, but didn't you all rename WebWork to XWork because WebWork was a misnomer? If the framework remains web-centric, why not just call it WebWork 1.4? Blake Day On Saturday, January 11, 2003, at 03:29 AM, Rickard Öberg wrote: This is a very difficult question. Separating it from the javax.servlet API should be possible, but overall I have the feeling that trying to make a *too* generic solution might be crippling. A little poll: *) How many have actions that are used with more than one kind of dispatcher? *) How many are using WebWork in Swing apps? *) How many are using WebWork for RPC style stuff? (the ClientServletDispatcher and friends) I don't use any of those and am quite unlikely to eve ruse them. Reason: I use app clients. webwork/xwork to me is ALL about being web only, and its role is to handle view related stuff and marshall things for the backend. EJBs do all the actual 'meat'. Appclients for me provide a far greater degree of separation, as if I went with the webwork framework for my swing clients, due to the possibility of wildly different UI's, I suspect I'd end up having to add a whole bunch of special chains/collections of actions for the appclients to use. I strongly suspect that swing/non web usage makes up 1% or less of all the users. Lets not make this unpleasant for the silent majority just to win a marketing line or two or some coolness points by saying 'we have nothing to do with the web!'. xwork should be targeted at the web, and should make the life of web developers a lot more pleasant and fun. It should NOT enforce that though and should work well outside of it, but web people should definitely be the main target audience. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork -- Michael Blake Day Artistry Studios mobile: 770.480.1547 --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XWork: core concepts
My point precisely. I think, given the current culture of XWork, we're looking at WW 2.0 (major revision change) instead of XWork... and the webwork name becomes appropriate. On Mon, 13 Jan 2003, Michael Blake Day wrote: Correct me if I'm wrong, but didn't you all rename WebWork to XWork because WebWork was a misnomer? If the framework remains web-centric, why not just call it WebWork 1.4? --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XWork: core concepts
Philipp Meier wrote: These are the core concepts that I can think of. Now, for my own portlet-ish needs (which I hope will be more common for others too in the future) the following applies: * Actions and Components, and their resulting views, are ALWAYS called through a servlet include. This means that the URL in a browser NEVER reveals that XWork is used. [...] Just to make it clear: This is your needs, right? It doesn't prevents us from having a filter or servlet based dispatcher like webwork has now, right? They could even live happily together with one mapped to *.action and the other mapped to sth. else. My needs include a dispatcher like the current, so I'm happy to work on providing one. It could be possible to add a flag for whether includes are mandatory or not. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XWork: core concepts
Peter Kelley wrote: Good to have you back I'm not back. I'm trying to see whether it's any point in me restarting the XWork. Are views a core concept ? Tricky one. Yes, I guess they should be, somehow. The other thing we might want to address is whether or not XWork will be somewhat seperated at the core from the web. This is a very difficult question. Separating it from the javax.servlet API should be possible, but overall I have the feeling that trying to make a *too* generic solution might be crippling. A little poll: *) How many have actions that are used with more than one kind of dispatcher? *) How many are using WebWork in Swing apps? *) How many are using WebWork for RPC style stuff? (the ClientServletDispatcher and friends) /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] XWork: core concepts
I'm looking into using Xworks mostly for actions with reuse of actions in all three settings. Main use: Swing/SWT application; secondly, webservices and web application. I'd be interested to see how the same action could be reused, with just switching of dispatcher/interceptor necessary for integration on each platform. My alternative is to roll my own action framework, with basically the same features that the core dispatcher and FactoryProxies has today (+ standard error reporting, transparent handling of Undo and some other things). I'm impressed by a lot of the stuff in WW today, so my guess is that it would in large parts be a rewrite of WW... But it would of course be preferrable to have a widely used framework instead (perhaps with readymade code for at least some of the usecases) ;-) cheers, /Måns -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Rickard Öberg Sent: den 11 januari 2003 09:30 To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] XWork: core concepts Peter Kelley wrote: Good to have you back I'm not back. I'm trying to see whether it's any point in me restarting the XWork. Are views a core concept ? Tricky one. Yes, I guess they should be, somehow. The other thing we might want to address is whether or not XWork will be somewhat seperated at the core from the web. This is a very difficult question. Separating it from the javax.servlet API should be possible, but overall I have the feeling that trying to make a *too* generic solution might be crippling. A little poll: *) How many have actions that are used with more than one kind of dispatcher? *) How many are using WebWork in Swing apps? *) How many are using WebWork for RPC style stuff? (the ClientServletDispatcher and friends) /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XWork: core concepts
+1 - Original Message - From: Hani Suleiman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 11, 2003 6:29 AM Subject: Re: [OS-webwork] XWork: core concepts On Saturday, January 11, 2003, at 03:29 AM, Rickard Öberg wrote: This is a very difficult question. Separating it from the javax.servlet API should be possible, but overall I have the feeling that trying to make a *too* generic solution might be crippling. A little poll: *) How many have actions that are used with more than one kind of dispatcher? *) How many are using WebWork in Swing apps? *) How many are using WebWork for RPC style stuff? (the ClientServletDispatcher and friends) I don't use any of those and am quite unlikely to eve ruse them. Reason: I use app clients. webwork/xwork to me is ALL about being web only, and its role is to handle view related stuff and marshall things for the backend. EJBs do all the actual 'meat'. Appclients for me provide a far greater degree of separation, as if I went with the webwork framework for my swing clients, due to the possibility of wildly different UI's, I suspect I'd end up having to add a whole bunch of special chains/collections of actions for the appclients to use. I strongly suspect that swing/non web usage makes up 1% or less of all the users. Lets not make this unpleasant for the silent majority just to win a marketing line or two or some coolness points by saying 'we have nothing to do with the web!'. xwork should be targeted at the web, and should make the life of web developers a lot more pleasant and fun. It should NOT enforce that though and should work well outside of it, but web people should definitely be the main target audience. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XWork: core concepts
It could be possible to add a flag for whether includes are mandatory or not. Seems like this is exactly what interceptors are for. You don't want to have actions accessible directly from a url? Then add the interceptor that prevents it. Anders Hovmöller [EMAIL PROTECTED] http://boxed.killingar.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XWork: core concepts
A little poll: As long as you are aware that any result from this poll is basically meaningless I'm fine with this. It was pretty obvious last time this type of thing was asked on the mailing list (URLTag) and it was acted on the result, that the response that was given was grossly misleading. Better safe then sorry, should be a design goal within OS just as minimising surprise is :P Now, to answer this myself: *) How many have actions that are used with more than one kind of dispatcher? I have at least two actions I want to execute also from a command line. *) How many are using WebWork in Swing apps? Not me, but I'd never touch Swing. I have from time to time considered using actions from SWT though. In my opinion, the only really solid argument for using WW over say Struts is that we are not locked up in a certain environment. I firmly believe that the core parts of XW can easily avoid being tied up to servlets, as WW does now. Note that this doesn't mean that the XW-servlet package, if you will, will be a lot easier to work with due to a number of features that simplify development. Drawing a line where servlet code can start in XW is very important, and since you don't really need to include ALL of XW in non-servlet code (after all you can't) this line doesn't need to be drawn so that the design is hampered in any way. The line is just so we can point to it and say: if you want to port this app to a non-servlet system don't cross this. Anders Hovmöller [EMAIL PROTECTED] http://boxed.killingar.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XWork: core concepts
boxed wrote: It could be possible to add a flag for whether includes are mandatory or not. Seems like this is exactly what interceptors are for. You don't want to have actions accessible directly from a url? Then add the interceptor that prevents it. Good point. That would work. /Rickard --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XWork: core concepts
Making unnecessary changes, IMHO, is definitely 'making it unpleasant'. While I see that backward compatibility is too hard to keep (or so I'm told) given all that people want xwork to be, I really dislike the approach of change for changes sake. I deliberately avoided the very early versions of webwork because I knew it's rapidly changing, and I'm not the kind of person that is very tolerant of non-backward compatible changes or changes that go in due to 'coolness' factor or some highschool concept of what constitutes good design when it comes to 'real' work. However, at this point I have a rather large number of classes built off of webwork actions. I suspect that there are many other webwork users in the same boat. Now, some of these users are hobbyists and don't mind tinkering about for fun and spending a few days porting their apps to xwork so they can be on the cool side of the fence again. However, I suspect many of these users are in the same situation I'm in, and do not look forward to changing all their existing code to support a new API that after all is said and done, ends up doing pretty much the same things they always did without much in the way of advantages. I wrote this mainly in response to the switch to Maps from ThreadLocals. All things being equal, I couldn't care less which is used. However, given the lack of strong reasons for either case, my vote very strongly goes towards keeping things the same. xwork is supposed to be a better, easier more configurable version of webwork for all its users, not the patrickization of webwork. On Saturday, January 11, 2003, at 03:20 PM, Patrick Lightbody wrote: No one is going to make it unpleasant... you can be sure of that. It'll be easier and more pleasant for everything. If you look at the CVS, I think you'll agree. Today I'm going to put in an Interceptor that reads a components.xml file, which contains a list of components, and pulls three things from the file: --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] XWork: core concepts
I agree here. I like having the safety of knowing that if we decide to re-architect the presentation layer of our app (and we're looking at re-doing some of it with Thinlets), then there could be a framework there to let us do that... -Original Message- From: Patrick Lightbody [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 11, 2003 11:10 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] XWork: core concepts I would highly recommend against going down this path. Otherwise, just focus on WebWork 1.4. Plus, even if all our actions are used for the web, remember that by making the core framework non-web-based, you also make testing much easier as well. -Pat - Original Message - From: matt baldree [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 11, 2003 5:34 AM Subject: Re: [OS-webwork] XWork: core concepts +1 - Original Message - From: Hani Suleiman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 11, 2003 6:29 AM Subject: Re: [OS-webwork] XWork: core concepts On Saturday, January 11, 2003, at 03:29 AM, Rickard Öberg wrote: This is a very difficult question. Separating it from the javax.servlet API should be possible, but overall I have the feeling that trying to make a *too* generic solution might be crippling. A little poll: *) How many have actions that are used with more than one kind of dispatcher? *) How many are using WebWork in Swing apps? *) How many are using WebWork for RPC style stuff? (the ClientServletDispatcher and friends) I don't use any of those and am quite unlikely to eve ruse them. Reason: I use app clients. webwork/xwork to me is ALL about being web only, and its role is to handle view related stuff and marshall things for the backend. EJBs do all the actual 'meat'. Appclients for me provide a far greater degree of separation, as if I went with the webwork framework for my swing clients, due to the possibility of wildly different UI's, I suspect I'd end up having to add a whole bunch of special chains/collections of actions for the appclients to use. I strongly suspect that swing/non web usage makes up 1% or less of all the users. Lets not make this unpleasant for the silent majority just to win a marketing line or two or some coolness points by saying 'we have nothing to do with the web!'. xwork should be targeted at the web, and should make the life of web developers a lot more pleasant and fun. It should NOT enforce that though and should work well outside of it, but web people should definitely be the main target audience. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] XWork: core concepts
On Fri, Jan 10, 2003 at 10:59:06AM +0100, Rickard Öberg wrote: These are the core concepts that I can think of. Now, for my own portlet-ish needs (which I hope will be more common for others too in the future) the following applies: * Actions and Components, and their resulting views, are ALWAYS called through a servlet include. This means that the URL in a browser NEVER reveals that XWork is used. [...] Just to make it clear: This is your needs, right? It doesn't prevents us from having a filter or servlet based dispatcher like webwork has now, right? They could even live happily together with one mapped to *.action and the other mapped to sth. else. My needs include a dispatcher like the current, so I'm happy to work on providing one. -billy. -- Meisterbohne Söflinger Straße 100 Tel: +49-731-399 499-0 eLösungen 89077 Ulm Fax: +49-731-399 499-9 msg01116/pgp0.pgp Description: PGP signature
Re: [OS-webwork] XWork: core concepts
Rickard, These are great, I've placed them on the Wiki (Which is now linked from the main site, yay!). -Pat - Original Message - From: Rickard Ã-berg [EMAIL PROTECTED] To: WebWork [EMAIL PROTECTED] Sent: Friday, January 10, 2003 1:59 AM Subject: [OS-webwork] XWork: core concepts All, Since quite a few of you disagreed with my resignation as XWork architect, I've given some thought to how it would be possible to merge my requirements with those that you have. It might be possible to do it, and if so I would reconsider re-starting my work on XWork. I'd like to begin with defining the core concepts that XWork would have, and also briefly list my requirements, and see what your thoughts on them are. The core concepts that I think must be included are the following: * Actions. These are the application implementations (generic or specific) that together define the behaviour of the application. No news here. * Interceptors. These are cross-cutting concerns that apply to several actions, and which may modify the behaviour of it, produce some side-effect to the execution of the Action, or modify the input or output of the Action. * Components. This is a new concept for WebWork. Instead of just having a bunch of non-related Action's, one would bundle some of them together into a Component. An Action may be part of several Components though. The main feature of a Component is to function as a state machine which determine what Action to execute during a page rendering. * Packages. Also a new concept. There are usually two approaches to configuration: coarse-grained or fine-grained. In the coarse-grained style a setting applies to EVERYTHING in the app. In the fine-grained style each part needs to be individually configured. The first focus on ease-of-use and the latter on flexibility. Packages allow for something in between. An Action, Interceptor or Component can be defined in a Package and can easily refer to one another within that package. By having hierarchical packages can easily refer to definitions in other Packages. For example, we would most likely define a number of Actions, Interceptors and possible Components that are in a default Package, which user Packages would then depend on. However, user Packages could then override any such definition made higher up. This gives the ease-of-use of a coarse-grained configuration together with the total control and flexibility of a fine-grained configuration, while still providing reasonably clear semantics. These are the core concepts that I can think of. Now, for my own portlet-ish needs (which I hope will be more common for others too in the future) the following applies: * Actions and Components, and their resulting views, are ALWAYS called through a servlet include. This means that the URL in a browser NEVER reveals that XWork is used. For example, an admin app would consist of an admin.jsp which includes the Actions/Components needed for that app. Not only does that make it easy to extend the admin app later on with more portlets, it also makes it possible (for those who are so inclined) to use J2EE declarative security very easily. Plus bookmarks are human-friendly. This means that the dispatcher would explicitly disallow Action invocation that are NOT a result of an include. This too adds some extra security, since only actions that YOU decide should be called are actually callable. Plus, your actions can decide much better in what order they are called, depending on your app requirements. The actual include would still be using the .action extension though. * For many simple portlets an include of a .action is fine. For complex portlets that require a state machine this is not ok. Instead, what one usually wants is to include a component that then delegates to some action depending on the *state* of some automata. This is similar to how the CardPane works in WebWork. Essentially, XWork would include this kind of state machine as a built-in concept instead of as an add-on like CardPane, since this is such an important and common case. It needs to be as simple and flexible as is possible. When a component renders its view it also creates URL's that define what the possible next states are. This means that the URL's in the generated HTML are shortlived (i.e. after one of the URL's have been clicked they are all invalid), which also means that it will be impossible to have a double form submit. After the first submit the URL will be invalid, so clicking again will not lead to a re-execution of the action. This also gives some extra security. * The execution of a Component (and maybe Action's too) needs to be split into two phases. The actual execution of an action is done at the *beginning* of a page render, and the rendering is done at the time of the include. Why? Because the action may influence what is shown on the page, and may also result in a redirect to another
