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.
