Exactly, although the old way is still an option.
Don
tm jee wrote:
Now if this is the case, may I read this is another configuration XML
file needed? IMO we should try to allow an application to work with
less and less configuration needed, and not the other way around. Or I
am looking at this from the wrong perspective?
I think (if not mistaken) is that the struts-plugin.xml would have the same definition as struts_x_x.dtd (the same definition as the current struts.xml uses).
The aim is such that when a jar is added to the classpath, if it has such a struts-plugin.xml,
will get its interceptor, packages etc registered just like a normal struts.xml would. The
benifit is that we don't need a <include file="..../struts-plugin.xml" /> being
defined in struts.xml. I guess thats the main motivation behind this idea. What do you think
Alex?
rgds
----- Original Message ----
From: Alexandru Popescu <[EMAIL PROTECTED]>
To: Struts Developers List <dev@struts.apache.org>
Sent: Friday, 29 September, 2006 3:13:19 AM
Subject: Re: Struts plugins
On 9/29/06, Don Brown <[EMAIL PROTECTED]> 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 if this is the case, may I read this is another configuration XML
file needed? IMO we should try to allow an application to work with
less and less configuration needed, and not the other way around. Or I
am looking at this from the wrong perspective?
./alex
--
.w( the_mindstorm )p.
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]
