From 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-action-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 -----
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?
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.
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.
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 -----
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:
<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
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.
