You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by David Graham <dg...@hotmail.com> on 2003/04/22 03:18:16 UTC
Tiles integration with Struts
IMO, deprecating these features is appropriate because it gives Tiles users
a chance to migrate to the Struts version. We don't have to remove them in
1.2 but the migration path should be clear.
David
> Changing the calls to TilesUtil.applicationClass() in favor of
>RequestUtils.applicationClass() introduce a dependencies on RequestUtils,
>which I would like to avoid and limit to few (struts related) classes.
> Limiting this dependency allow to use the tiles package without struts.
>Don't ask me why, but there is some users that want to use only tiles,
>without struts.
> It is why I have created a TilesUtil class with different implementations
>depending on what the users want:
>
> * TilesUtilImpl: default impl, used without struts
> * TilesUtilStrutsImpl: impl for struts (1.0.x and 1.1 without modules)
> * TilesUtilStrutsModulesImpl: impl for struts1.1 with modules
>
> So, to be able to use Tiles without Struts and fix the bug 19070, we
>should:
>
> * TilesUtil.applicationClass() should not be deprecated now (maybe
> in a later major release). (revert to previous version)
> * TilesUtilImpl.java should not depend on RequestUtils, so it should
> not be modified. (revert to previous version)
> * TilePlugin should use RequestUtils.applicationClass() (keep the
> modification) <-- this should fixe the bug
> * TilesServlet is used to initialize the tiles factory without
> Struts. It should not be deprecated (revert to previous version)
> * ComponentDefinition should not depend on RequestUtils (revert to
> previous version)
> * TilesUtilStrutsImpl (revert to previous version)
>
> Cedric
>
>
>>
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Tiles integration with Struts
Posted by James Mitchell <jm...@apache.org>.
> As struts committers
> There seems to be really only 2 options,
> 1) Tiles stays and adheres to the same rules as other code.
> An entirely independent decision is whether to fork
> the code base and host it on sourceforge or elsewhere
> to support non-struts use.
+1
>
> 2) Remove/deprecate Tiles entirely.
>
> How do we want to proceed ?
>
--
James Mitchell
Software Developer/Struts Evangelist
http://www.open-tools.org
----- Original Message -----
From: "Robert Leland" <rl...@apache.org>
To: "Struts Developers List" <st...@jakarta.apache.org>
Sent: Tuesday, April 22, 2003 11:52 AM
Subject: Re: Tiles integration with Struts
> +1, For directly addressing the matter.
> One set of rules for all code.
>
> As struts committers
> There seems to be really only 2 options,
> 1) Tiles stays and adheres to the same rules as other code.
> An entirely independent decision is whether to fork
> the code base and host it on sourceforge or elsewhere
> to support non-struts use.
>
> 2) Remove/deprecate Tiles entirely.
>
> How do we want to proceed ?
>
> Martin Cooper wrote:
> > If there is code required to use Tiles outside of Struts, then I believe
> > that code should *not* be part of the Struts code base. That code should
be
> > part of an independent component that allows Tiles to work elsewhere.
> >
> > Tiles is an integral part of Struts today, and Struts is not in the
business
> > of providing packages for use elsewhere. In Struts 1.0, we had
functionality
> > that was later deemed to be generally useful. Because of this, we pulled
it
> > out of Struts after the 1.0 release, and it became the basis of several
> > Commons packages. Struts' focus needs to remain on Struts.
> >
> > IMNSHO, we need to make up our mind once and for all as to whether Tiles
> > should continue to be an integral part of Struts, or go back to being an
> > independent package that can be hooked up to Struts, amongst other
> > frameworks and applications. If it's part of Struts, then we (the Struts
> > developers) have no responsibility for ensuring that it be usable
outside of
> > Struts. (If someone else wants to do that, that's fine, but we should
not
> > pander to that.)
> >
> > Don't get me wrong - I think Tiles is valuable, and I use it myself. But
I
> > get frustrated every time I see Tiles trying to lead a double life as a
> > "part of Struts but also independent of Struts". If there is a desire to
> > make it independently usable, then we should pull it back out of Struts
and
> > make it a separate Jakarta component, just as we have done with
Validator,
> > BeanUtils, FileUpload and others. Otherwise, it becomes part of Struts,
> > period.
> >
> > --
> > Martin Cooper
> >
> > PS - </end-rant> ;-}
> >
> >
> > "David Graham" <dg...@hotmail.com> wrote in message
> > news:Law15-F82zPLC6MlhgQ0000a6f2@hotmail.com...
> >
> >>IMO, deprecating these features is appropriate because it gives Tiles
> >
> > users
> >
> >>a chance to migrate to the Struts version. We don't have to remove them
> >
> > in
> >
> >>1.2 but the migration path should be clear.
> >>
> >>David
> >>
> >>
> >>
> >>> Changing the calls to TilesUtil.applicationClass() in favor of
> >>>RequestUtils.applicationClass() introduce a dependencies on
RequestUtils,
> >>>which I would like to avoid and limit to few (struts related) classes.
> >>> Limiting this dependency allow to use the tiles package without
struts.
> >>>Don't ask me why, but there is some users that want to use only tiles,
> >>>without struts.
> >>> It is why I have created a TilesUtil class with different
> >
> > implementations
> >
> >>>depending on what the users want:
> >>>
> >>> * TilesUtilImpl: default impl, used without struts
> >>> * TilesUtilStrutsImpl: impl for struts (1.0.x and 1.1 without
> >
> > modules)
> >
> >>> * TilesUtilStrutsModulesImpl: impl for struts1.1 with modules
> >>>
> >>> So, to be able to use Tiles without Struts and fix the bug 19070, we
> >>>should:
> >>>
> >>> * TilesUtil.applicationClass() should not be deprecated now (maybe
> >>> in a later major release). (revert to previous version)
> >>> * TilesUtilImpl.java should not depend on RequestUtils, so it should
> >>> not be modified. (revert to previous version)
> >>> * TilePlugin should use RequestUtils.applicationClass() (keep the
> >>> modification) <-- this should fixe the bug
> >>> * TilesServlet is used to initialize the tiles factory without
> >>> Struts. It should not be deprecated (revert to previous version)
> >>> * ComponentDefinition should not depend on RequestUtils (revert to
> >>> previous version)
> >>> * TilesUtilStrutsImpl (revert to previous version)
> >>>
> >>> Cedric
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Tiles integration with Struts
Posted by Robert Leland <rl...@apache.org>.
+1, For directly addressing the matter.
One set of rules for all code.
As struts committers
There seems to be really only 2 options,
1) Tiles stays and adheres to the same rules as other code.
An entirely independent decision is whether to fork
the code base and host it on sourceforge or elsewhere
to support non-struts use.
2) Remove/deprecate Tiles entirely.
How do we want to proceed ?
Martin Cooper wrote:
> If there is code required to use Tiles outside of Struts, then I believe
> that code should *not* be part of the Struts code base. That code should be
> part of an independent component that allows Tiles to work elsewhere.
>
> Tiles is an integral part of Struts today, and Struts is not in the business
> of providing packages for use elsewhere. In Struts 1.0, we had functionality
> that was later deemed to be generally useful. Because of this, we pulled it
> out of Struts after the 1.0 release, and it became the basis of several
> Commons packages. Struts' focus needs to remain on Struts.
>
> IMNSHO, we need to make up our mind once and for all as to whether Tiles
> should continue to be an integral part of Struts, or go back to being an
> independent package that can be hooked up to Struts, amongst other
> frameworks and applications. If it's part of Struts, then we (the Struts
> developers) have no responsibility for ensuring that it be usable outside of
> Struts. (If someone else wants to do that, that's fine, but we should not
> pander to that.)
>
> Don't get me wrong - I think Tiles is valuable, and I use it myself. But I
> get frustrated every time I see Tiles trying to lead a double life as a
> "part of Struts but also independent of Struts". If there is a desire to
> make it independently usable, then we should pull it back out of Struts and
> make it a separate Jakarta component, just as we have done with Validator,
> BeanUtils, FileUpload and others. Otherwise, it becomes part of Struts,
> period.
>
> --
> Martin Cooper
>
> PS - </end-rant> ;-}
>
>
> "David Graham" <dg...@hotmail.com> wrote in message
> news:Law15-F82zPLC6MlhgQ0000a6f2@hotmail.com...
>
>>IMO, deprecating these features is appropriate because it gives Tiles
>
> users
>
>>a chance to migrate to the Struts version. We don't have to remove them
>
> in
>
>>1.2 but the migration path should be clear.
>>
>>David
>>
>>
>>
>>> Changing the calls to TilesUtil.applicationClass() in favor of
>>>RequestUtils.applicationClass() introduce a dependencies on RequestUtils,
>>>which I would like to avoid and limit to few (struts related) classes.
>>> Limiting this dependency allow to use the tiles package without struts.
>>>Don't ask me why, but there is some users that want to use only tiles,
>>>without struts.
>>> It is why I have created a TilesUtil class with different
>
> implementations
>
>>>depending on what the users want:
>>>
>>> * TilesUtilImpl: default impl, used without struts
>>> * TilesUtilStrutsImpl: impl for struts (1.0.x and 1.1 without
>
> modules)
>
>>> * TilesUtilStrutsModulesImpl: impl for struts1.1 with modules
>>>
>>> So, to be able to use Tiles without Struts and fix the bug 19070, we
>>>should:
>>>
>>> * TilesUtil.applicationClass() should not be deprecated now (maybe
>>> in a later major release). (revert to previous version)
>>> * TilesUtilImpl.java should not depend on RequestUtils, so it should
>>> not be modified. (revert to previous version)
>>> * TilePlugin should use RequestUtils.applicationClass() (keep the
>>> modification) <-- this should fixe the bug
>>> * TilesServlet is used to initialize the tiles factory without
>>> Struts. It should not be deprecated (revert to previous version)
>>> * ComponentDefinition should not depend on RequestUtils (revert to
>>> previous version)
>>> * TilesUtilStrutsImpl (revert to previous version)
>>>
>>> Cedric
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Tiles integration with Struts
Posted by James Mitchell <jm...@apache.org>.
Could we propose a commons-tiles?
--
James Mitchell
Software Developer/Struts Evangelist
http://www.open-tools.org
----- Original Message -----
From: "Martin Cooper" <ma...@apache.org>
To: <st...@jakarta.apache.org>
Sent: Tuesday, April 22, 2003 1:18 AM
Subject: Re: Tiles integration with Struts
> If there is code required to use Tiles outside of Struts, then I believe
> that code should *not* be part of the Struts code base. That code should
be
> part of an independent component that allows Tiles to work elsewhere.
>
> Tiles is an integral part of Struts today, and Struts is not in the
business
> of providing packages for use elsewhere. In Struts 1.0, we had
functionality
> that was later deemed to be generally useful. Because of this, we pulled
it
> out of Struts after the 1.0 release, and it became the basis of several
> Commons packages. Struts' focus needs to remain on Struts.
>
> IMNSHO, we need to make up our mind once and for all as to whether Tiles
> should continue to be an integral part of Struts, or go back to being an
> independent package that can be hooked up to Struts, amongst other
> frameworks and applications. If it's part of Struts, then we (the Struts
> developers) have no responsibility for ensuring that it be usable outside
of
> Struts. (If someone else wants to do that, that's fine, but we should not
> pander to that.)
>
> Don't get me wrong - I think Tiles is valuable, and I use it myself. But I
> get frustrated every time I see Tiles trying to lead a double life as a
> "part of Struts but also independent of Struts". If there is a desire to
> make it independently usable, then we should pull it back out of Struts
and
> make it a separate Jakarta component, just as we have done with Validator,
> BeanUtils, FileUpload and others. Otherwise, it becomes part of Struts,
> period.
>
> --
> Martin Cooper
>
> PS - </end-rant> ;-}
>
>
> "David Graham" <dg...@hotmail.com> wrote in message
> news:Law15-F82zPLC6MlhgQ0000a6f2@hotmail.com...
> > IMO, deprecating these features is appropriate because it gives Tiles
> users
> > a chance to migrate to the Struts version. We don't have to remove them
> in
> > 1.2 but the migration path should be clear.
> >
> > David
> >
> >
> > > Changing the calls to TilesUtil.applicationClass() in favor of
> > >RequestUtils.applicationClass() introduce a dependencies on
RequestUtils,
> > >which I would like to avoid and limit to few (struts related) classes.
> > > Limiting this dependency allow to use the tiles package without
struts.
> > >Don't ask me why, but there is some users that want to use only tiles,
> > >without struts.
> > > It is why I have created a TilesUtil class with different
> implementations
> > >depending on what the users want:
> > >
> > > * TilesUtilImpl: default impl, used without struts
> > > * TilesUtilStrutsImpl: impl for struts (1.0.x and 1.1 without
> modules)
> > > * TilesUtilStrutsModulesImpl: impl for struts1.1 with modules
> > >
> > > So, to be able to use Tiles without Struts and fix the bug 19070, we
> > >should:
> > >
> > > * TilesUtil.applicationClass() should not be deprecated now (maybe
> > > in a later major release). (revert to previous version)
> > > * TilesUtilImpl.java should not depend on RequestUtils, so it
should
> > > not be modified. (revert to previous version)
> > > * TilePlugin should use RequestUtils.applicationClass() (keep the
> > > modification) <-- this should fixe the bug
> > > * TilesServlet is used to initialize the tiles factory without
> > > Struts. It should not be deprecated (revert to previous version)
> > > * ComponentDefinition should not depend on RequestUtils (revert to
> > > previous version)
> > > * TilesUtilStrutsImpl (revert to previous version)
> > >
> > > Cedric
> > >
> > >
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > >For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> > >
> >
> >
> > _________________________________________________________________
> > Add photos to your e-mail with MSN 8. Get 2 months FREE*.
> > http://join.msn.com/?page=features/featuredemail
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Tiles integration with Struts
Posted by Cedric Dumoulin <ce...@apache.org>.
Maintaining an "hybrid" version of Tiles (working with and without
Struts) becomes a nightmare for me. Furthermore, it bring unnecessary
complexity to the code. It is hard for me to break such work, but you
--all-- convince me that it is time to do it.
So, I agree to let Tiles to be fully part of Struts, and to directly
use Struts code (like RequestUtils...). If later we feel that Tiles
should be moved elsewhere, this still possible.
Cedric
Martin Cooper wrote:
>If there is code required to use Tiles outside of Struts, then I believe
>that code should *not* be part of the Struts code base. That code should be
>part of an independent component that allows Tiles to work elsewhere.
>
>Tiles is an integral part of Struts today, and Struts is not in the business
>of providing packages for use elsewhere. In Struts 1.0, we had functionality
>that was later deemed to be generally useful. Because of this, we pulled it
>out of Struts after the 1.0 release, and it became the basis of several
>Commons packages. Struts' focus needs to remain on Struts.
>
>IMNSHO, we need to make up our mind once and for all as to whether Tiles
>should continue to be an integral part of Struts, or go back to being an
>independent package that can be hooked up to Struts, amongst other
>frameworks and applications. If it's part of Struts, then we (the Struts
>developers) have no responsibility for ensuring that it be usable outside of
>Struts. (If someone else wants to do that, that's fine, but we should not
>pander to that.)
>
>Don't get me wrong - I think Tiles is valuable, and I use it myself. But I
>get frustrated every time I see Tiles trying to lead a double life as a
>"part of Struts but also independent of Struts". If there is a desire to
>make it independently usable, then we should pull it back out of Struts and
>make it a separate Jakarta component, just as we have done with Validator,
>BeanUtils, FileUpload and others. Otherwise, it becomes part of Struts,
>period.
>
>--
>Martin Cooper
>
>PS - </end-rant> ;-}
>
>
>"David Graham" <dg...@hotmail.com> wrote in message
>news:Law15-F82zPLC6MlhgQ0000a6f2@hotmail.com...
>
>
>>IMO, deprecating these features is appropriate because it gives Tiles
>>
>>
>users
>
>
>>a chance to migrate to the Struts version. We don't have to remove them
>>
>>
>in
>
>
>>1.2 but the migration path should be clear.
>>
>>David
>>
>>
>>
>>
>>> Changing the calls to TilesUtil.applicationClass() in favor of
>>>RequestUtils.applicationClass() introduce a dependencies on RequestUtils,
>>>which I would like to avoid and limit to few (struts related) classes.
>>> Limiting this dependency allow to use the tiles package without struts.
>>>Don't ask me why, but there is some users that want to use only tiles,
>>>without struts.
>>> It is why I have created a TilesUtil class with different
>>>
>>>
>implementations
>
>
>>>depending on what the users want:
>>>
>>> * TilesUtilImpl: default impl, used without struts
>>> * TilesUtilStrutsImpl: impl for struts (1.0.x and 1.1 without
>>>
>>>
>modules)
>
>
>>> * TilesUtilStrutsModulesImpl: impl for struts1.1 with modules
>>>
>>> So, to be able to use Tiles without Struts and fix the bug 19070, we
>>>should:
>>>
>>> * TilesUtil.applicationClass() should not be deprecated now (maybe
>>> in a later major release). (revert to previous version)
>>> * TilesUtilImpl.java should not depend on RequestUtils, so it should
>>> not be modified. (revert to previous version)
>>> * TilePlugin should use RequestUtils.applicationClass() (keep the
>>> modification) <-- this should fixe the bug
>>> * TilesServlet is used to initialize the tiles factory without
>>> Struts. It should not be deprecated (revert to previous version)
>>> * ComponentDefinition should not depend on RequestUtils (revert to
>>> previous version)
>>> * TilesUtilStrutsImpl (revert to previous version)
>>>
>>> Cedric
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>_________________________________________________________________
>>Add photos to your e-mail with MSN 8. Get 2 months FREE*.
>>http://join.msn.com/?page=features/featuredemail
>>
>>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Tiles integration with Struts
Posted by Mohan Kishore <mo...@yahoo.com>.
+1
--- Martin Cooper <ma...@apache.org> wrote:
> If there is code required to use Tiles outside of Struts, then I believe
> that code should *not* be part of the Struts code base. That code should be
> part of an independent component that allows Tiles to work elsewhere.
>
> Tiles is an integral part of Struts today, and Struts is not in the business
> of providing packages for use elsewhere. In Struts 1.0, we had functionality
> that was later deemed to be generally useful. Because of this, we pulled it
> out of Struts after the 1.0 release, and it became the basis of several
> Commons packages. Struts' focus needs to remain on Struts.
>
> IMNSHO, we need to make up our mind once and for all as to whether Tiles
> should continue to be an integral part of Struts, or go back to being an
> independent package that can be hooked up to Struts, amongst other
> frameworks and applications. If it's part of Struts, then we (the Struts
> developers) have no responsibility for ensuring that it be usable outside of
> Struts. (If someone else wants to do that, that's fine, but we should not
> pander to that.)
>
> Don't get me wrong - I think Tiles is valuable, and I use it myself. But I
> get frustrated every time I see Tiles trying to lead a double life as a
> "part of Struts but also independent of Struts". If there is a desire to
> make it independently usable, then we should pull it back out of Struts and
> make it a separate Jakarta component, just as we have done with Validator,
> BeanUtils, FileUpload and others. Otherwise, it becomes part of Struts,
> period.
>
> --
> Martin Cooper
>
> PS - </end-rant> ;-}
>
>
> "David Graham" <dg...@hotmail.com> wrote in message
> news:Law15-F82zPLC6MlhgQ0000a6f2@hotmail.com...
> > IMO, deprecating these features is appropriate because it gives Tiles
> users
> > a chance to migrate to the Struts version. We don't have to remove them
> in
> > 1.2 but the migration path should be clear.
> >
> > David
> >
> >
> > > Changing the calls to TilesUtil.applicationClass() in favor of
> > >RequestUtils.applicationClass() introduce a dependencies on RequestUtils,
> > >which I would like to avoid and limit to few (struts related) classes.
> > > Limiting this dependency allow to use the tiles package without struts.
> > >Don't ask me why, but there is some users that want to use only tiles,
> > >without struts.
> > > It is why I have created a TilesUtil class with different
> implementations
> > >depending on what the users want:
> > >
> > > * TilesUtilImpl: default impl, used without struts
> > > * TilesUtilStrutsImpl: impl for struts (1.0.x and 1.1 without
> modules)
> > > * TilesUtilStrutsModulesImpl: impl for struts1.1 with modules
> > >
> > > So, to be able to use Tiles without Struts and fix the bug 19070, we
> > >should:
> > >
> > > * TilesUtil.applicationClass() should not be deprecated now (maybe
> > > in a later major release). (revert to previous version)
> > > * TilesUtilImpl.java should not depend on RequestUtils, so it should
> > > not be modified. (revert to previous version)
> > > * TilePlugin should use RequestUtils.applicationClass() (keep the
> > > modification) <-- this should fixe the bug
> > > * TilesServlet is used to initialize the tiles factory without
> > > Struts. It should not be deprecated (revert to previous version)
> > > * ComponentDefinition should not depend on RequestUtils (revert to
> > > previous version)
> > > * TilesUtilStrutsImpl (revert to previous version)
> > >
> > > Cedric
> > >
> > >
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > >For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> > >
> >
> >
> > _________________________________________________________________
> > Add photos to your e-mail with MSN 8. Get 2 months FREE*.
> > http://join.msn.com/?page=features/featuredemail
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Tiles integration with Struts
Posted by Martin Cooper <ma...@apache.org>.
If there is code required to use Tiles outside of Struts, then I believe
that code should *not* be part of the Struts code base. That code should be
part of an independent component that allows Tiles to work elsewhere.
Tiles is an integral part of Struts today, and Struts is not in the business
of providing packages for use elsewhere. In Struts 1.0, we had functionality
that was later deemed to be generally useful. Because of this, we pulled it
out of Struts after the 1.0 release, and it became the basis of several
Commons packages. Struts' focus needs to remain on Struts.
IMNSHO, we need to make up our mind once and for all as to whether Tiles
should continue to be an integral part of Struts, or go back to being an
independent package that can be hooked up to Struts, amongst other
frameworks and applications. If it's part of Struts, then we (the Struts
developers) have no responsibility for ensuring that it be usable outside of
Struts. (If someone else wants to do that, that's fine, but we should not
pander to that.)
Don't get me wrong - I think Tiles is valuable, and I use it myself. But I
get frustrated every time I see Tiles trying to lead a double life as a
"part of Struts but also independent of Struts". If there is a desire to
make it independently usable, then we should pull it back out of Struts and
make it a separate Jakarta component, just as we have done with Validator,
BeanUtils, FileUpload and others. Otherwise, it becomes part of Struts,
period.
--
Martin Cooper
PS - </end-rant> ;-}
"David Graham" <dg...@hotmail.com> wrote in message
news:Law15-F82zPLC6MlhgQ0000a6f2@hotmail.com...
> IMO, deprecating these features is appropriate because it gives Tiles
users
> a chance to migrate to the Struts version. We don't have to remove them
in
> 1.2 but the migration path should be clear.
>
> David
>
>
> > Changing the calls to TilesUtil.applicationClass() in favor of
> >RequestUtils.applicationClass() introduce a dependencies on RequestUtils,
> >which I would like to avoid and limit to few (struts related) classes.
> > Limiting this dependency allow to use the tiles package without struts.
> >Don't ask me why, but there is some users that want to use only tiles,
> >without struts.
> > It is why I have created a TilesUtil class with different
implementations
> >depending on what the users want:
> >
> > * TilesUtilImpl: default impl, used without struts
> > * TilesUtilStrutsImpl: impl for struts (1.0.x and 1.1 without
modules)
> > * TilesUtilStrutsModulesImpl: impl for struts1.1 with modules
> >
> > So, to be able to use Tiles without Struts and fix the bug 19070, we
> >should:
> >
> > * TilesUtil.applicationClass() should not be deprecated now (maybe
> > in a later major release). (revert to previous version)
> > * TilesUtilImpl.java should not depend on RequestUtils, so it should
> > not be modified. (revert to previous version)
> > * TilePlugin should use RequestUtils.applicationClass() (keep the
> > modification) <-- this should fixe the bug
> > * TilesServlet is used to initialize the tiles factory without
> > Struts. It should not be deprecated (revert to previous version)
> > * ComponentDefinition should not depend on RequestUtils (revert to
> > previous version)
> > * TilesUtilStrutsImpl (revert to previous version)
> >
> > Cedric
> >
> >
> >>
> >>
> >>
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
>
>
> _________________________________________________________________
> Add photos to your e-mail with MSN 8. Get 2 months FREE*.
> http://join.msn.com/?page=features/featuredemail
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org