The primary goal of this "plugin" design is to help us organize our
framework code, and make it easier for folks to use optional features,
"Just drop in the jar." However, since it is really just a set of
conventions, it could be used for an application -
"struts-default.xml,struts-plugin.xml,struts-app-plugin.xml, struts.xml".
Where this idea breaks down is when you have a complex hierarchy of
modules and dependencies that can't be broken down into a one or two
level structure. In that case, I'd go back to the one struts.xml that
includes others. The older style of configuration still works.
As for annotations, this is really orthogonal to them. Yes, we'd like
to use them more heavily so that you may skip the XML altogether, but
that's another subject. For those that use XML, and those that want to
use plugins without having to define results, interceptors, stacks, and
actions from scratch, this should help.
Don
Ian Roughley wrote:
Do you see plug-in's being used for enhancing the framework features,
for adding "modules" to web apps or both? I ask this because the list
of possible plug-ins so far see to be framework related. The ordering
that Toby suggested seems to make more sense from a web-app
perspective (as features of one web-app may depend on another module
being loaded), or both?
We should also consider annotations. Using annotations would we need
the xml file at all? Or should it be included so that we are
declaratively specifying what we want to be running, rather than
what's in the classpath.
/Ian
Don Brown wrote:
While I appreciate the idea, I don't particularly think that plugins
should be deterministic. Perhaps plugin is the wrong word as it
brings to mind descriptors, versioning, dependencies, etc. for some
people. In this case, I see it as simply a way to organize code and
provide default configuration for that code. Anything that is common
to multiple plugins should be pushed into the core.
Now, since the names of what configuration files are configurable,
you could change it to load "struts-default.xml, struts-plugin.xml,
struts-plugin-ext.xml, struts.xml" or whatever other files you'd
like. From a core framework POV, I think simply loading
struts-plugin.xml in a non-deterministic order is fine for our needs.
Don
tm jee wrote:
Hi guys, Just some thoughts, maybe we could have an order
parameter introduced eg
struts-plugin.xml
<struts>
<param name="order">10</param>
<package ....>
</package>
</struts>
So we could have control of which plugin gets the priority when
loading and we could defined order 1-100 is for struts, custom
plugin starts from 101 etc. Ordering for plugins with same ordering
would be undefined. The ordering could maybe applied only to plugin
(struts-plugin.xml) as we have just one bootstrap configuration
(struts.xml)
Thoughts?
rgds
----- Original Message ----
From: David H. DeWolf <[EMAIL PROTECTED]>
To: Struts Developers List <dev@struts.apache.org>
Sent: Thursday, 28 September, 2006 12:15:12 AM
Subject: Re: Struts plugins
Not sure if this is exactly what you're looking for, but the patch
to upgrade from 0.2 to 2.0 exists:
https://issues.apache.org/struts/browse/WW-1418
Also, while you're looking at this, here's another patch related to
tiles that I'd be interested in:
https://issues.apache.org/struts/browse/WW-1450
David
Don Brown wrote:
Is there any Tiles 2 migration code I can put into a block or does
it need to be written yet? I do agree it would be a great candidate.
Don
Antonio Petrelli wrote:
Don Brown ha scritto:
The first batch of plugins:
1. Configuration Browser
2. Jasper Reports
3. JFreeChart
4. JSF
5. Pell Multipart handler
6. Sitemesh
7. Struts 1
You forgot Tiles 2 :-)
Ciao
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
