Agreed. I like things being simple but I don't like making things confusing and awkward in the name of simplicity.
If some sort of "default" action thing does get put in, though, I would recommend that it be specific to webwork. Xwork doesn't need it; it's really only appropriate for simplifying web development (though it will only simplify things for the first 10 minutes you use webwork and then get in your way after that). If you're using xwork standalone (which I am), it has the potential to create subtle, difficult to track errors. A command framework should only implement the commands that are explicitly stated. If a web framework wants some default commands to make web development easy, then more power to it. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pat Lightbody Sent: Wednesday, August 20, 2003 8:34 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Simplicity of WW2 I'm not too happy with the idea of a default-action-package. I never really liked it in WebWork1 and I still don't like it. It confuses refactoring tools a whole bunch and doesn't seem to offer that much (how hard is it to copy-and-past?). As for executing actions that aren't defined in xwork.xml explicitely (not defaults)-- that scares me. -Pat ----- Original Message ----- From: "John Patterson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, August 19, 2003 7:01 AM Subject: Re: [OS-webwork] Simplicity of WW2 MessageFrom a given alias (eg '/products/search') both a default Action would need to be found and a default Result. Currently the behaviour of this search is defined by the abstract factory, DefaultActionProxyFactory. This factory creates a DefaultActionProxy instance which creates an ActionInvocation from the runtime config on each request. It is in the DefaultActionInvocation that the action class and result class are instantiated. I suggest that if an ActionConfig is not found in the runtime config then a default one is created and cached for future use. This would occur in the DefaultActionProxy class at the time of lookup. The class name would be derived from the action name ('search' becomes 'SearchAction'). The package would come from the <default-action-package> defined for the package (ie 'com.mycompany.myapp') and the action namespace and action name would be appended giving 'com.mycompany.myapp.products.SearchAction'. The Result type (for WW) would normally be either ServletDispatcherResult or VelocityResult. This would require the functionality to be configurable (ie not a part of XWork). The WW default config could define a <default-result-factory> element which defines the class that contains the logic for the result search. For example, a ServletDispatcherDefaultResultFactory could define the logic to find the correct jsp page. By default it would look for a file named '/products/search.jsp'. If the jsp file is found then the factory would return a ResultConfig object which would be cached for future use against the result key 'SUCCESS' (maybe 'INPUT' also). Global results could be accessed from the action also (eg LOGIN). These factories could be chained together so that applications that use XWork can define an ordered succession of factories (eg look for jsp then velocity templates). When extending a package with another package the default behaviour could also be extended. Another java package may be defined in which to search for actions or an additional factory could be added to create ResultConfig's. For the end user in the most simple case they would not have to create *any* additional configuration. They could create action classes in the default package (no package name) and jsp's or vm's in the web root. The config browser xwork.xml file would become: <xwork> <include file="webwork-default.xml"/> <package name="default" extends="webwork-default" namespace="/"> <default-action-package>com.opensymphony.webwork.config_browser</default -act ion-package> <interceptors> <interceptor-stack name="config-browser-default"> <interceptor-ref name="component"/> <interceptor-ref name="validationWorkflowStack"/> </interceptor-stack> </interceptors> <default-interceptor-ref name="config-browser-default"/> <global-results> <result name="error" type="velocity">error.vm</result> </global-results> </package> </xwork> Now that would be simple! John. ----- Original Message ----- From: Jason Carreira To: [EMAIL PROTECTED] Sent: Monday, August 18, 2003 6:40 PM Subject: RE: [OS-webwork] Simplicity of WW2 How would you suggest it's found? How does it default? How are views defined? How does it know what class you're talking about? What about extending a package with another package? -----Original Message----- From: John Patterson [mailto:[EMAIL PROTECTED] Sent: Monday, August 18, 2003 12:29 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Simplicity of WW2 My issue was not with fully qualified names in the xwork.xml file. I agree that this would not be worth the extra complexity. I would like to avoid creating *any* entry in the config for simple actions. Only create an entry in the config when the default behaviour is not sufficient. Performance would not be an issue as once the default action configuration has been found once, it could be cached and reused (just as with explicity defined actions). -----Original Message----- From: Cameron Braid [mailto:[EMAIL PROTECTED] Sent: Friday, August 15, 2003 8:58 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Simplicity of WW2 I would think that using the fully qualified classname isn't any harder since most of the time you are copy pasting it anyway. Also, when using refactoring tools to rename classes, or move them, the tools can often update xml or text files. This wouldn't work with short names. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Carreira Sent: Friday, 15 August 2003 2:15 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Simplicity of WW2 Create a jira for <default-action-package> for XWork 1.0 and we'll take a look at what it will take to make it happen. -----Original Message----- From: John Patterson [mailto:[EMAIL PROTECTED] Sent: Thursday, August 14, 2003 4:00 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Simplicity of WW2 That is a great improvement! Still one extra step per action though. It would not be very often that one would want to change the default action-view search behaviour. Just setting a java package property would be enough (<defaultActionPackage>com.myorg.myapp.actions</...). I just thought that if I saw such an ease of use feature when looking for a framework that would have impressed me. I hate having to configure things with xml that should be default. One more step that can go wrong. Smart defaults are a developers friend. ----- Original Message ----- From: Jason Carreira To: [EMAIL PROTECTED] Sent: Thursday, August 14, 2003 7:51 PM Subject: RE: [OS-webwork] Simplicity of WW2 I'm not sure about this... this sounds more complicated to me than explicitly telling it what to look for... you have to read a lot more docs for what the defaults are, etc. With the stuff I did to make the default stuff pulled out into a separate file, here's what the xwork.xml for the Config Browser app looks like: <!DOCTYPE xwork PUBLIC "-//OpenSymphony Group//XWork 1.0//EN" "http://www.opensymphony.com/xwork/xwork-1.0.dtd";> <xwork> <include file="webwork-default.xml"/> <package name="default" extends="webwork-default" namespace="/"> <interceptors> <interceptor-stack name="config-browser-default"> <interceptor-ref name="component"/> <interceptor-ref name="validationWorkflowStack"/> </interceptor-stack> </interceptors> <default-interceptor-ref name="config-browser-default"/> <global-results> <result name="error" type="velocity">error.vm</result> </global-results> <action name="namespace" class="com.opensymphony.webwork.config_browser.NamespaceAction"> <result type="velocity" name="success">namespaces.vm</result> <result type="velocity" name="input">namespaces.vm</result> </action> <action name="actionNames" class="com.opensymphony.webwork.config_browser.ActionNamesAction"> <result type="velocity" name="success">actionNames.vm</result> <result type="velocity" name="input">actionNames.vm</result> </action> <action name="showConfig" class="com.opensymphony.webwork.config_browser.ShowConfigAction"> <result type="velocity" name="success">showConfig.vm</result> <result type="velocity" name="input">showConfig.vm</result> </action> </package> </xwork> That's the whole thing. It's pretty simple, I think. Jason -----Original Message----- From: John Patterson [mailto:[EMAIL PROTECTED] Sent: Thursday, August 14, 2003 7:40 AM To: Webwork Subject: [OS-webwork] Simplicity of WW2 When searching for a good web framework I looked for simplicity first and power second. The thing which stood out about WW1 was that it seemed easier to get new actions up and running quickly. Being able to define a default package made the config very simple. I think that some of this has been lost in WW2. I would like to suggest the ability to have "default" mappings between action aliases, action classes and views so that if I enter the URL "/action/search" or "search.action" the framework will look for a class named SearchAction and a view of "/search.jsp" (success result). This must be able to be configured so that instead of jsp some other view technology could be used as the default. The directory in which the default jsp view should be searched for should also be able to be specified ("/" as default) The action search path should be able to be specified. If an action with a namespace is used ("/products/search") then the action class should be searched for in the sub package "products" of every package in the search path. Of course this would only work for actions that only need one specific result (may use global results) To my mind, this kind of shortcut makes a framework appear easy to use. In reality it is easy to configure every action in your xml file but it is an obvious way to show "look how easy it is to use Webwork". The fine grained control would remain for more complicated actions. John. ------------------------------------------------------- This SF.net email is sponsored by Dice.com. Did you know that Dice has over 25,000 tech jobs available today? From careers in IT to Engineering to Tech Sales, Dice has tech jobs from the best hiring companies. http://www.dice.com/index.epl?rel_code=104 _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
