Could you translate these ideas into JIRA tickets and mark them
against 2.1? After I finish with the XWork refactoring, I'd like to
work on making the configuration providers pluggable, because as you
said, it really opens up some interesting possibilities. It is
kinda
tricky as you have a chicken-egg situation with providers that
create
plugins which create providers, so patches would be very welcome :)
Don
On 9/12/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
Well, the configuration provider is kinda a pain right now. I
started a
thread a while back about making configuration providers
pluggable via
the
struts-plugin.xml file. I think it sorta died because you can
use init
parameters to setup providers in web.xml.
In addition, if you want to use the extensionless support as
well as
all
the index support of the plugin it requires a completely different
filter,
but it would be much nicer to have everything just plug-in and
run with
as
little configuration as possible.
If we keep it a plugin then I would suggest removing zero-
config from
core
so that they don't conflict. I'd probably also want to rework the
DispatcherFilter to make it more pluggable so that the majority
of the
work
is from injections and then it can be changed without modifying the
web.xml.
Lastly, the configuration providers need to be easier to setup.
This
would
probably require a more robust configuration mechanism that would
pre-inject
configuration providers and then inject the rest of the container.
However, all that said, I think this should be in core. The
beauty of
frameworks like Rails and Grails is that they give all the
conventions
right
out of the box. I feel like Struts should try to strive to match
the
ease of
these other frameworks. Otherwise, it requires the users to
actually
know
that the plugin exists, go find it, install it and then learn it
all.
-bp
Don Brown wrote:
The reason the zero config stuff is in core is mainly because it
requires a configuration provider, which cannot be plugged in via a
struts plugin. Is there any other technical reason that this should
be in core?
Don
On 9/11/07, Musachy Barroso <[EMAIL PROTECTED]> wrote:
IMO this should be a "core" feature of struts 2.
musachy
On 9/10/07, Don Brown <[EMAIL PROTECTED]> wrote:
Hmm...along those lines, could SmartURL be Codebehind 2.0?
As for 2.1, I'm working on a huge patch to xwork 2.1 that will,
among
other things, make OGNL pluggable and fully migrate the code to
container injection (no statics!). I should be done sometime this
week.
Don
On 9/11/07, Ted Husted <[EMAIL PROTECTED]> wrote:
Why wait? People using Struts 2.0.x could use it now. Struts 2.1.x
could be out next week, or next month, or next year. There's
really no
telling.
I'm not sure what "rolling it into the core" means. If it means
putting the source into the Struts-Core JAR, then I'd probably be
opposed. Personally, I'd like to keep rolling things out of the
core
and distribute as much as possible in the form of plugins.
Ultimately,
there should be nothing in the core that doesn't *need* to be in
the
core. My thought would be to include SmartURLs in Struts 2.1.x
as the
successor to the CodeBehind plugin.
-Ted.
On 9/10/07, Musachy Barroso <[EMAIL PROTECTED]> wrote:
+1 for waiting and rolling it into core, it could be available
for 2.1
musachy
On 9/10/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
I was planning on release 1.0 of SmartURLs in the near future
and doing
some announcements to the user lists and some other locations.
However,
should I wait on that if favor of rolling this back into core,
or should
I go ahead?
Thoughts?
-bp
-------------------------------------------------------------------
--
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]
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
-------------------------------------------------------------------
--
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]
