On Wednesday 20 August 2003 17:34, Pat Lightbody wrote:
> 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?).
>
+1
> As for executing actions that aren't defined in xwork.xml explicitely (not
> defaults)-- that scares me.
>
> -Pat
Scares me too. I hate those frameworks / tools / whatever where I have to find
some hint (hopefully existing) in the last corner of the docs about which
amazing things are done behind my back because they are configured
"implicitely".
Have a look at xwork.xml: You do not have to read a single line of doc to
understand nearly perfectly what is done and when it is done. I liked that
from the first moment on.
Regards,
- Rene
>
> ----- 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-ac
>t 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.
> [..]
--
Rene Gielen | Fon. (+49)-241-4010770
Saarstr. 100 | Fax. (+49)-241-4010771
52062 Aachen | [EMAIL PROTECTED]
-------------------------------------------------------
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
