On 9/29/06, tm jee <[EMAIL PROTECTED]> 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?
If this is the case, than yeah, it makes sense.
./alex
--
.w( the_mindstorm )p.
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]
