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.
