You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by gr...@intellicare.com on 2005/08/24 16:04:06 UTC
Shale and Tiles integration - where oh where is shale-tiles.jar?
Hi again,
So now that I have a trivial login page working, I want to integrate tiles
in..:) I found this link:
http://jroller.com/page/dgeary?entry=shale_adds_tiles_integration
which seems pretty promising. But there's mention of a shale-tiles.jar but
no word about where to download it..? Googling for it brought no joy
either...(:( Some other place (I forget where, I've been so all over..)
said something about a standalone tiles which I did find (but that's
called tiles.core)..
So.. (sigh..) I have to ask for help again.. thanks once again in advance!
Geeta
Re: Standalone Tiles - JSP version & tld file
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/25/05, David Geary <sa...@earthlink.net> wrote:
> Le 05-08-25 à 10:53, Craig McClanahan a écrit :
>
> > On 8/25/05, Greg Reddin <gr...@fnf.com> wrote:
> >
> >> On Aug 25, 2005, at 12:28 AM, Craig McClanahan wrote:
> >>
> >>> However, I've got a separate / semi-related question. Given that
> >>> we're changing package names anyway, it would be really cool to
> >>> abstract away the servlet API specific calling sequences, so that
> >>> standalone Tiles could work equally comfortably in a portlet
> >>> environment (without needing any portlet->servlet bridgework). The
> >>> only API a typical Tiles user will be using is Controller, so this
> >>> shouldn't be a huge deal. What do you think?
>
> Abstracting out the servlet API will break controllers because we're
> passing HttpServletRequest, HttpServletResponse, and ServletContext
> to the controller's perform and execute methods. Would we change
> those method signatures to take an external context instead?
Ideally, yes ... but note that changing the package name breaks
existing uses of Controller as well. It would seem reasonable for the
Struts integration layer to keep a copy of the old Controller
interface (under the old package name), so people could continue to
run -- but when the developer switches to the standalone Tiles version
of Controller they would have to migrate to the external context
thing.
If that's too harsh, we could probably have old-style and new-style
versions of Controller in standalone Tiles (so that the framework
would no which one to call), with the limitation that old-style
controllers would not work in portlets.
> david
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by Ted Husted <te...@gmail.com>.
If you guys are ready to do the work, I'd say let's just do it, and we
can use Tiles subproject with Classic 1.3.x. We're shipping
subprojects in this release series, and we might as well just ship
them all and be done with it. Having two versions of Tiles is likely
to cause more confusion than the edge cases are worth. And, if we are
fixing other things along the way, anyone who might be within those
edge cases (if any) might be happy for the improvements.
I could refactor MailReader to use Tiles (rather than JSP:include) as
a simple test bed and resurrect/repair the Tiles demonstration
application, to exercise advanced features. As long as Tiles works the
same from the configuration-file layer, I'd say we're OK.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by David Geary <sa...@earthlink.net>.
Le 05-08-25 à 13:24, Craig McClanahan a écrit :
> On 8/25/05, Greg Reddin <gr...@fnf.com> wrote:
>
>> On Aug 25, 2005, at 1:55 PM, David Geary wrote:
>>
>>> I'm +1 for this, but should we make plugging standalone Tiles back
>>> into Struts
>>> a priority and tackle this once that's done? Perhaps it's unfounded,
>>> but I'm
>>> concerned that the current Tiles will change if we don't act
>>> quickly.
>>>
>>
>> If Tiles needs more changes wouldn't it be easier to implement them
>> while it's still in the Sandbox than when it becomes a sub-project or
>> whatever? Once something is published it will be more difficult to
>> change it. So, what are the changes? In addition to Craig's
>> idea of
>> externalizing the Servlet API I'd like to further refine the
>> ComponentDefinition class. xmlDefinition extends ComponentDefinition
>> and does some stuff that, it seems to me, should be moved up to the
>> base level. Possibly, the whole xmlDefinitiion package could go away
>> and be merged up. Right now I think it's a bit of a mess b/c I
>> merged
>> some of it up but not the rest. OTOH, that wouldn't affect users
>> unless they are subclassing DefinitionsFactory or
>> ComponentDefinitions
>> or something.
I doubt there are many folks who've done that, so I wouldn't be too
squeamish
about that refactoring. Others, of course, may disagree.
>> Either way, because Standalone Tiles has changed so much internally
>> from the integrated version we should probably be real careful about
>> how it's brought back in. I guess we could deprecate
>> org.apache.struts.tiles and bring in org.apache.tiles.
I'm not sure what that deprecation would entail. We'd have to make
sure that
everything in o.a.s.t gets rewired to work with standalone Tiles,
right? Perhaps
we could just yank o.a.s.t entirely and replace it with o.a.t. I
doubt that many
people reference o.a.s.t in their code, with the exception of
controllers.
Does anyone have a feel for what else it'd take to unplug the current
Tiles from
Struts and plug in standalone Tiles? I haven't mucked around in Struts
proper code for quite some time, so it's a mystery to me.
david
>>
>> Sorry, this is kinda random. As Craig said once, we have one shot at
>> changing things while Tiles is in the sandbox. I'd hate for us to
>> wrap
>> that up prematurely.
>
> Sandbox or subproject doesn't really make any difference on being able
> to refine APIs, until standalone Tiles does a 1.0 release. From that
> point on is where you'd want the APIs to be stable.
>
>
>> Greg
>>
>
> Craig
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/25/05, Greg Reddin <gr...@fnf.com> wrote:
> On Aug 25, 2005, at 1:55 PM, David Geary wrote:
> > I'm +1 for this, but should we make plugging standalone Tiles back
> > into Struts
> > a priority and tackle this once that's done? Perhaps it's unfounded,
> > but I'm
> > concerned that the current Tiles will change if we don't act quickly.
>
> If Tiles needs more changes wouldn't it be easier to implement them
> while it's still in the Sandbox than when it becomes a sub-project or
> whatever? Once something is published it will be more difficult to
> change it. So, what are the changes? In addition to Craig's idea of
> externalizing the Servlet API I'd like to further refine the
> ComponentDefinition class. xmlDefinition extends ComponentDefinition
> and does some stuff that, it seems to me, should be moved up to the
> base level. Possibly, the whole xmlDefinitiion package could go away
> and be merged up. Right now I think it's a bit of a mess b/c I merged
> some of it up but not the rest. OTOH, that wouldn't affect users
> unless they are subclassing DefinitionsFactory or ComponentDefinitions
> or something.
>
> Either way, because Standalone Tiles has changed so much internally
> from the integrated version we should probably be real careful about
> how it's brought back in. I guess we could deprecate
> org.apache.struts.tiles and bring in org.apache.tiles.
>
> Sorry, this is kinda random. As Craig said once, we have one shot at
> changing things while Tiles is in the sandbox. I'd hate for us to wrap
> that up prematurely.
>
Sandbox or subproject doesn't really make any difference on being able
to refine APIs, until standalone Tiles does a 1.0 release. From that
point on is where you'd want the APIs to be stable.
> Greg
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by Greg Reddin <gr...@fnf.com>.
On Aug 25, 2005, at 1:55 PM, David Geary wrote:
> I'm +1 for this, but should we make plugging standalone Tiles back
> into Struts
> a priority and tackle this once that's done? Perhaps it's unfounded,
> but I'm
> concerned that the current Tiles will change if we don't act quickly.
If Tiles needs more changes wouldn't it be easier to implement them
while it's still in the Sandbox than when it becomes a sub-project or
whatever? Once something is published it will be more difficult to
change it. So, what are the changes? In addition to Craig's idea of
externalizing the Servlet API I'd like to further refine the
ComponentDefinition class. xmlDefinition extends ComponentDefinition
and does some stuff that, it seems to me, should be moved up to the
base level. Possibly, the whole xmlDefinitiion package could go away
and be merged up. Right now I think it's a bit of a mess b/c I merged
some of it up but not the rest. OTOH, that wouldn't affect users
unless they are subclassing DefinitionsFactory or ComponentDefinitions
or something.
Either way, because Standalone Tiles has changed so much internally
from the integrated version we should probably be real careful about
how it's brought back in. I guess we could deprecate
org.apache.struts.tiles and bring in org.apache.tiles.
Sorry, this is kinda random. As Craig said once, we have one shot at
changing things while Tiles is in the sandbox. I'd hate for us to wrap
that up prematurely.
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by David Geary <sa...@earthlink.net>.
Le 05-08-25 à 10:53, Craig McClanahan a écrit :
> On 8/25/05, Greg Reddin <gr...@fnf.com> wrote:
>
>> On Aug 25, 2005, at 12:28 AM, Craig McClanahan wrote:
>>
>>> However, I've got a separate / semi-related question. Given that
>>> we're changing package names anyway, it would be really cool to
>>> abstract away the servlet API specific calling sequences, so that
>>> standalone Tiles could work equally comfortably in a portlet
>>> environment (without needing any portlet->servlet bridgework). The
>>> only API a typical Tiles user will be using is Controller, so this
>>> shouldn't be a huge deal. What do you think?
Abstracting out the servlet API will break controllers because we're
passing HttpServletRequest, HttpServletResponse, and ServletContext
to the controller's perform and execute methods. Would we change
those method signatures to take an external context instead?
>>>
>>> If we're ever going to do this to standalone Tiles, pre-1.0 would
>>> seem
>>> like the right time.
>>>
>>
>> I agree with that. My refactoring job pushed it up to the level of
>> TilesUtil. Are you saying we should take it out of TilesUtil also?
>
> It's not just TilesUtil (your refactoring narrowed the amount of work
> needed, though). A large number of the method signatures throughout
> Tiles take a ServletContext, HttpServletRequest, or
> HttpServletResponse parameter. None of that will work in a portlet
> environment (which provides
> PortletContext/PortletRequest/PortletResponse APIs) without bridging
> layers to adapt backwards.
>
> The way JSF approached this was to define an ExternalContext API that
> abstracted away the differences. I'd propose to do something like
> that for standalone Tiles, and pass such a context object around,
> instead of the individual servlet API dependent objects.
I'm +1 for this, but should we make plugging standalone Tiles back
into Struts
a priority and tackle this once that's done? Perhaps it's unfounded,
but I'm
concerned that the current Tiles will change if we don't act quickly.
david
>
> Craig
>
>
>> Greg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/25/05, Greg Reddin <gr...@fnf.com> wrote:
> On Aug 25, 2005, at 12:28 AM, Craig McClanahan wrote:
>
> > However, I've got a separate / semi-related question. Given that
> > we're changing package names anyway, it would be really cool to
> > abstract away the servlet API specific calling sequences, so that
> > standalone Tiles could work equally comfortably in a portlet
> > environment (without needing any portlet->servlet bridgework). The
> > only API a typical Tiles user will be using is Controller, so this
> > shouldn't be a huge deal. What do you think?
> >
> > If we're ever going to do this to standalone Tiles, pre-1.0 would seem
> > like the right time.
>
> I agree with that. My refactoring job pushed it up to the level of
> TilesUtil. Are you saying we should take it out of TilesUtil also?
>
It's not just TilesUtil (your refactoring narrowed the amount of work
needed, though). A large number of the method signatures throughout
Tiles take a ServletContext, HttpServletRequest, or
HttpServletResponse parameter. None of that will work in a portlet
environment (which provides
PortletContext/PortletRequest/PortletResponse APIs) without bridging
layers to adapt backwards.
The way JSF approached this was to define an ExternalContext API that
abstracted away the differences. I'd propose to do something like
that for standalone Tiles, and pass such a context object around,
instead of the individual servlet API dependent objects.
Craig
> Greg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by Greg Reddin <gr...@fnf.com>.
On Aug 25, 2005, at 12:28 AM, Craig McClanahan wrote:
> However, I've got a separate / semi-related question. Given that
> we're changing package names anyway, it would be really cool to
> abstract away the servlet API specific calling sequences, so that
> standalone Tiles could work equally comfortably in a portlet
> environment (without needing any portlet->servlet bridgework). The
> only API a typical Tiles user will be using is Controller, so this
> shouldn't be a huge deal. What do you think?
>
> If we're ever going to do this to standalone Tiles, pre-1.0 would seem
> like the right time.
I agree with that. My refactoring job pushed it up to the level of
TilesUtil. Are you saying we should take it out of TilesUtil also?
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/25/05, James Mitchell <jm...@apache.org> wrote:
> +1
>
> That's pretty much my experience too.
>
> So, with that said, can we move standalone to subproject level or are
> we waiting on something?
>
One interesting wrinkle is that "Integrated Tiles" (the version that
has org.apache.struts.tiles package names) currently occupies the
"tiles" directory name at the subproject level. It would likely make
sense to migrate (svn move) that to some other directory name, and
adjust the Struts Classic build processes, before moving "Standalone
Tiles" up a level.
Craig
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> Consulting / Mentoring / Freelance
> EdgeTech, Inc.
> http://www.edgetechservices.net/
> 678.910.8017
> AIM: jmitchtx
> Yahoo: jmitchtx
> MSN: jmitchell@apache.org
> Skype: jmitchtx
>
>
>
> On Aug 25, 2005, at 1:44 AM, Martin Cooper wrote:
>
> > On 8/24/05, Craig McClanahan <cr...@gmail.com> wrote:
> >
> >> On 8/24/05, James Mitchell <jm...@apache.org> wrote:
> >>
> >>> Sorry if I'm piping up late on this.
> >>>
> >>> What's the plans for Tiles? Will we support embedded tiles or will
> >>> we simply adapt standalone to work as we do for the commons stuff?
> >>>
> >>>
> >>
> >> That's definitely a call for the developers invested in 1.3.x, but it
> >> certainly makes the most sense to have one and only one
> >> implementation
> >> around, and just do bindings to it. Such bindings should be very
> >> easy
> >> in this case.
> >>
> >
> > My preference would definitely be to support only one version, with
> > that version being the one we expect to support in future releases.
> > So, +1 for supporting Standalone Tiles only.
> >
> >
> >> However, I've got a separate / semi-related question. Given that
> >> we're changing package names anyway, it would be really cool to
> >> abstract away the servlet API specific calling sequences, so that
> >> standalone Tiles could work equally comfortably in a portlet
> >> environment (without needing any portlet->servlet bridgework). The
> >> only API a typical Tiles user will be using is Controller, so this
> >> shouldn't be a huge deal. What do you think?
> >>
> >
> > I'd say go for it. I would be *very* surprised if any more than a tiny
> > minority of Tiles users have any dependency on the Tiles API at all.
> > In my experience, the vast majority of Tiles users know little more
> > than they need to know to define their tiles in the tiles-defs.xml
> > file.
> >
> > --
> > Martin Cooper
> >
> >
> >
> >> If we're ever going to do this to standalone Tiles, pre-1.0 would
> >> seem
> >> like the right time.
> >>
> >> Craig
> >>
> >>
> >>>
> >>> --
> >>> James Mitchell
> >>> Software Engineer / Open Source Evangelist
> >>> Consulting / Mentoring / Freelance
> >>> EdgeTech, Inc.
> >>> http://www.edgetechservices.net/
> >>> 678.910.8017
> >>> AIM: jmitchtx
> >>> Yahoo: jmitchtx
> >>> MSN: jmitchell@apache.org
> >>> Skype: jmitchtx
> >>>
> >>>
> >>>
> >>> On Aug 25, 2005, at 1:00 AM, Craig McClanahan wrote:
> >>>
> >>>
> >>>> On 8/24/05, Martin Cooper <mf...@gmail.com> wrote:
> >>>>
> >>>>
> >>>>> On 8/24/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> >>>>>
> >>>>>
> >>>>>> From: <gr...@intellicare.com> (on struts-user)
> >>>>>>
> >>>>>>
> >>>>>>> test.jsp has this:
> >>>>>>> <%@ taglib uri="http://jakarta.apache.org/tiles"
> >>>>>>> prefix="tiles" %>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> Jakarta? That can't be right... there's a problem:
> >>>>>>
> >>>>>> The tld in last night's tiles-core.jar has a JSP 1.1 tld with
> >>>>>> that uri,
> >>>>>> which is coming from src/conf.
> >>>>>>
> >>>>>> I noticed that tld the other day when I was changing the Maven
> >>>>>> build files.
> >>>>>> The doc/userGuide/tiles-core.xml file does have the right uri. I
> >>>>>> think the
> >>>>>> one in src/conf needs to be deleted-- the tld is probably still
> >>>>>> supposed to
> >>>>>> be generated from the files under doc/userGuide and doc/
> >>>>>> stylesheets as part
> >>>>>> of the build.
> >>>>>>
> >>>>>> Eventually I'll generate a complete tld with all the
> >>>>>> documentation, so that
> >>>>>> Maven can create the taglibdoc and tag reference pages... the
> >>>>>> one in
> >>>>>> src/conf doesn't have any of that.
> >>>>>>
> >>>>>> And what JSP version is Standalone Tiles using? The build files
> >>>>>> declare a
> >>>>>> dependency on Servlet 2.4 and JSP 2.0. I thought the intent was
> >>>>>> for Struts
> >>>>>> Classic (which is now at Servlet 2.3) to move to Standalone
> >>>>>> Tiles. Is that
> >>>>>> going to be possible with the mismatch in dependencies?
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> I believe the intent was that Standalone Tiles should rely on
> >>>>> Servlets
> >>>>> 2.3 and JSP 1.2, as does Struts Classic. I hope that's still the
> >>>>> case,
> >>>>> and that we just need to fix up Tiles to conform to that.
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> Yes, that was definitely the intent for Standalone Tiles. It
> >>>> probably
> >>>> got mixed up during the multiple iterations of cut-n-paste from the
> >>>> Struts-embedded sources, plus cut-n-paste changes to the build
> >>>> environment, plus ...
> >>>>
> >>>> Craig
> >>>>
> >>>>
> >>>>
> >>>>> --
> >>>>> Martin Cooper
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> --
> >>>>>> Wendy
> >>>>>>
> >>>>>>
> >>>>>> -----------------------------------------------------------------
> >>>>>> ---
> >>>>>> -
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>>>>> For additional commands, e-mail: dev-help@struts.apache.org
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> ------------------------------------------------------------------
> >>>>> ---
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>>>> For additional commands, e-mail: dev-help@struts.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> -------------------------------------------------------------------
> >>>> --
> >>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>>> For additional commands, e-mail: dev-help@struts.apache.org
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --------------------------------------------------------------------
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>> For additional commands, e-mail: dev-help@struts.apache.org
> >>>
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by James Mitchell <jm...@apache.org>.
+1
That's pretty much my experience too.
So, with that said, can we move standalone to subproject level or are
we waiting on something?
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: jmitchell@apache.org
Skype: jmitchtx
On Aug 25, 2005, at 1:44 AM, Martin Cooper wrote:
> On 8/24/05, Craig McClanahan <cr...@gmail.com> wrote:
>
>> On 8/24/05, James Mitchell <jm...@apache.org> wrote:
>>
>>> Sorry if I'm piping up late on this.
>>>
>>> What's the plans for Tiles? Will we support embedded tiles or will
>>> we simply adapt standalone to work as we do for the commons stuff?
>>>
>>>
>>
>> That's definitely a call for the developers invested in 1.3.x, but it
>> certainly makes the most sense to have one and only one
>> implementation
>> around, and just do bindings to it. Such bindings should be very
>> easy
>> in this case.
>>
>
> My preference would definitely be to support only one version, with
> that version being the one we expect to support in future releases.
> So, +1 for supporting Standalone Tiles only.
>
>
>> However, I've got a separate / semi-related question. Given that
>> we're changing package names anyway, it would be really cool to
>> abstract away the servlet API specific calling sequences, so that
>> standalone Tiles could work equally comfortably in a portlet
>> environment (without needing any portlet->servlet bridgework). The
>> only API a typical Tiles user will be using is Controller, so this
>> shouldn't be a huge deal. What do you think?
>>
>
> I'd say go for it. I would be *very* surprised if any more than a tiny
> minority of Tiles users have any dependency on the Tiles API at all.
> In my experience, the vast majority of Tiles users know little more
> than they need to know to define their tiles in the tiles-defs.xml
> file.
>
> --
> Martin Cooper
>
>
>
>> If we're ever going to do this to standalone Tiles, pre-1.0 would
>> seem
>> like the right time.
>>
>> Craig
>>
>>
>>>
>>> --
>>> James Mitchell
>>> Software Engineer / Open Source Evangelist
>>> Consulting / Mentoring / Freelance
>>> EdgeTech, Inc.
>>> http://www.edgetechservices.net/
>>> 678.910.8017
>>> AIM: jmitchtx
>>> Yahoo: jmitchtx
>>> MSN: jmitchell@apache.org
>>> Skype: jmitchtx
>>>
>>>
>>>
>>> On Aug 25, 2005, at 1:00 AM, Craig McClanahan wrote:
>>>
>>>
>>>> On 8/24/05, Martin Cooper <mf...@gmail.com> wrote:
>>>>
>>>>
>>>>> On 8/24/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
>>>>>
>>>>>
>>>>>> From: <gr...@intellicare.com> (on struts-user)
>>>>>>
>>>>>>
>>>>>>> test.jsp has this:
>>>>>>> <%@ taglib uri="http://jakarta.apache.org/tiles"
>>>>>>> prefix="tiles" %>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Jakarta? That can't be right... there's a problem:
>>>>>>
>>>>>> The tld in last night's tiles-core.jar has a JSP 1.1 tld with
>>>>>> that uri,
>>>>>> which is coming from src/conf.
>>>>>>
>>>>>> I noticed that tld the other day when I was changing the Maven
>>>>>> build files.
>>>>>> The doc/userGuide/tiles-core.xml file does have the right uri. I
>>>>>> think the
>>>>>> one in src/conf needs to be deleted-- the tld is probably still
>>>>>> supposed to
>>>>>> be generated from the files under doc/userGuide and doc/
>>>>>> stylesheets as part
>>>>>> of the build.
>>>>>>
>>>>>> Eventually I'll generate a complete tld with all the
>>>>>> documentation, so that
>>>>>> Maven can create the taglibdoc and tag reference pages... the
>>>>>> one in
>>>>>> src/conf doesn't have any of that.
>>>>>>
>>>>>> And what JSP version is Standalone Tiles using? The build files
>>>>>> declare a
>>>>>> dependency on Servlet 2.4 and JSP 2.0. I thought the intent was
>>>>>> for Struts
>>>>>> Classic (which is now at Servlet 2.3) to move to Standalone
>>>>>> Tiles. Is that
>>>>>> going to be possible with the mismatch in dependencies?
>>>>>>
>>>>>>
>>>>>
>>>>> I believe the intent was that Standalone Tiles should rely on
>>>>> Servlets
>>>>> 2.3 and JSP 1.2, as does Struts Classic. I hope that's still the
>>>>> case,
>>>>> and that we just need to fix up Tiles to conform to that.
>>>>>
>>>>>
>>>>>
>>>>
>>>> Yes, that was definitely the intent for Standalone Tiles. It
>>>> probably
>>>> got mixed up during the multiple iterations of cut-n-paste from the
>>>> Struts-embedded sources, plus cut-n-paste changes to the build
>>>> environment, plus ...
>>>>
>>>> Craig
>>>>
>>>>
>>>>
>>>>> --
>>>>> Martin Cooper
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> --
>>>>>> Wendy
>>>>>>
>>>>>>
>>>>>> -----------------------------------------------------------------
>>>>>> ---
>>>>>> -
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> ---
>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by Ted Husted <te...@gmail.com>.
On 8/25/05, Martin Cooper <mf...@gmail.com> wrote:
> My preference would definitely be to support only one version, with
> that version being the one we expect to support in future releases.
> So, +1 for supporting Standalone Tiles only.
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by Martin Cooper <mf...@gmail.com>.
On 8/24/05, Craig McClanahan <cr...@gmail.com> wrote:
> On 8/24/05, James Mitchell <jm...@apache.org> wrote:
> > Sorry if I'm piping up late on this.
> >
> > What's the plans for Tiles? Will we support embedded tiles or will
> > we simply adapt standalone to work as we do for the commons stuff?
> >
>
> That's definitely a call for the developers invested in 1.3.x, but it
> certainly makes the most sense to have one and only one implementation
> around, and just do bindings to it. Such bindings should be very easy
> in this case.
My preference would definitely be to support only one version, with
that version being the one we expect to support in future releases.
So, +1 for supporting Standalone Tiles only.
> However, I've got a separate / semi-related question. Given that
> we're changing package names anyway, it would be really cool to
> abstract away the servlet API specific calling sequences, so that
> standalone Tiles could work equally comfortably in a portlet
> environment (without needing any portlet->servlet bridgework). The
> only API a typical Tiles user will be using is Controller, so this
> shouldn't be a huge deal. What do you think?
I'd say go for it. I would be *very* surprised if any more than a tiny
minority of Tiles users have any dependency on the Tiles API at all.
In my experience, the vast majority of Tiles users know little more
than they need to know to define their tiles in the tiles-defs.xml
file.
--
Martin Cooper
> If we're ever going to do this to standalone Tiles, pre-1.0 would seem
> like the right time.
>
> Craig
>
> >
> > --
> > James Mitchell
> > Software Engineer / Open Source Evangelist
> > Consulting / Mentoring / Freelance
> > EdgeTech, Inc.
> > http://www.edgetechservices.net/
> > 678.910.8017
> > AIM: jmitchtx
> > Yahoo: jmitchtx
> > MSN: jmitchell@apache.org
> > Skype: jmitchtx
> >
> >
> >
> > On Aug 25, 2005, at 1:00 AM, Craig McClanahan wrote:
> >
> > > On 8/24/05, Martin Cooper <mf...@gmail.com> wrote:
> > >
> > >> On 8/24/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> > >>
> > >>> From: <gr...@intellicare.com> (on struts-user)
> > >>>
> > >>>> test.jsp has this:
> > >>>> <%@ taglib uri="http://jakarta.apache.org/tiles" prefix="tiles" %>
> > >>>>
> > >>>
> > >>> Jakarta? That can't be right... there's a problem:
> > >>>
> > >>> The tld in last night's tiles-core.jar has a JSP 1.1 tld with
> > >>> that uri,
> > >>> which is coming from src/conf.
> > >>>
> > >>> I noticed that tld the other day when I was changing the Maven
> > >>> build files.
> > >>> The doc/userGuide/tiles-core.xml file does have the right uri. I
> > >>> think the
> > >>> one in src/conf needs to be deleted-- the tld is probably still
> > >>> supposed to
> > >>> be generated from the files under doc/userGuide and doc/
> > >>> stylesheets as part
> > >>> of the build.
> > >>>
> > >>> Eventually I'll generate a complete tld with all the
> > >>> documentation, so that
> > >>> Maven can create the taglibdoc and tag reference pages... the one in
> > >>> src/conf doesn't have any of that.
> > >>>
> > >>> And what JSP version is Standalone Tiles using? The build files
> > >>> declare a
> > >>> dependency on Servlet 2.4 and JSP 2.0. I thought the intent was
> > >>> for Struts
> > >>> Classic (which is now at Servlet 2.3) to move to Standalone
> > >>> Tiles. Is that
> > >>> going to be possible with the mismatch in dependencies?
> > >>>
> > >>
> > >> I believe the intent was that Standalone Tiles should rely on
> > >> Servlets
> > >> 2.3 and JSP 1.2, as does Struts Classic. I hope that's still the
> > >> case,
> > >> and that we just need to fix up Tiles to conform to that.
> > >>
> > >>
> > >
> > > Yes, that was definitely the intent for Standalone Tiles. It probably
> > > got mixed up during the multiple iterations of cut-n-paste from the
> > > Struts-embedded sources, plus cut-n-paste changes to the build
> > > environment, plus ...
> > >
> > > Craig
> > >
> > >
> > >> --
> > >> Martin Cooper
> > >>
> > >>
> > >>
> > >>> --
> > >>> Wendy
> > >>>
> > >>>
> > >>> --------------------------------------------------------------------
> > >>> -
> > >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > >>> For additional commands, e-mail: dev-help@struts.apache.org
> > >>>
> > >>>
> > >>>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > >> For additional commands, e-mail: dev-help@struts.apache.org
> > >>
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/24/05, James Mitchell <jm...@apache.org> wrote:
> Sorry if I'm piping up late on this.
>
> What's the plans for Tiles? Will we support embedded tiles or will
> we simply adapt standalone to work as we do for the commons stuff?
>
That's definitely a call for the developers invested in 1.3.x, but it
certainly makes the most sense to have one and only one implementation
around, and just do bindings to it. Such bindings should be very easy
in this case.
However, I've got a separate / semi-related question. Given that
we're changing package names anyway, it would be really cool to
abstract away the servlet API specific calling sequences, so that
standalone Tiles could work equally comfortably in a portlet
environment (without needing any portlet->servlet bridgework). The
only API a typical Tiles user will be using is Controller, so this
shouldn't be a huge deal. What do you think?
If we're ever going to do this to standalone Tiles, pre-1.0 would seem
like the right time.
Craig
>
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> Consulting / Mentoring / Freelance
> EdgeTech, Inc.
> http://www.edgetechservices.net/
> 678.910.8017
> AIM: jmitchtx
> Yahoo: jmitchtx
> MSN: jmitchell@apache.org
> Skype: jmitchtx
>
>
>
> On Aug 25, 2005, at 1:00 AM, Craig McClanahan wrote:
>
> > On 8/24/05, Martin Cooper <mf...@gmail.com> wrote:
> >
> >> On 8/24/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> >>
> >>> From: <gr...@intellicare.com> (on struts-user)
> >>>
> >>>> test.jsp has this:
> >>>> <%@ taglib uri="http://jakarta.apache.org/tiles" prefix="tiles" %>
> >>>>
> >>>
> >>> Jakarta? That can't be right... there's a problem:
> >>>
> >>> The tld in last night's tiles-core.jar has a JSP 1.1 tld with
> >>> that uri,
> >>> which is coming from src/conf.
> >>>
> >>> I noticed that tld the other day when I was changing the Maven
> >>> build files.
> >>> The doc/userGuide/tiles-core.xml file does have the right uri. I
> >>> think the
> >>> one in src/conf needs to be deleted-- the tld is probably still
> >>> supposed to
> >>> be generated from the files under doc/userGuide and doc/
> >>> stylesheets as part
> >>> of the build.
> >>>
> >>> Eventually I'll generate a complete tld with all the
> >>> documentation, so that
> >>> Maven can create the taglibdoc and tag reference pages... the one in
> >>> src/conf doesn't have any of that.
> >>>
> >>> And what JSP version is Standalone Tiles using? The build files
> >>> declare a
> >>> dependency on Servlet 2.4 and JSP 2.0. I thought the intent was
> >>> for Struts
> >>> Classic (which is now at Servlet 2.3) to move to Standalone
> >>> Tiles. Is that
> >>> going to be possible with the mismatch in dependencies?
> >>>
> >>
> >> I believe the intent was that Standalone Tiles should rely on
> >> Servlets
> >> 2.3 and JSP 1.2, as does Struts Classic. I hope that's still the
> >> case,
> >> and that we just need to fix up Tiles to conform to that.
> >>
> >>
> >
> > Yes, that was definitely the intent for Standalone Tiles. It probably
> > got mixed up during the multiple iterations of cut-n-paste from the
> > Struts-embedded sources, plus cut-n-paste changes to the build
> > environment, plus ...
> >
> > Craig
> >
> >
> >> --
> >> Martin Cooper
> >>
> >>
> >>
> >>> --
> >>> Wendy
> >>>
> >>>
> >>> --------------------------------------------------------------------
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>> For additional commands, e-mail: dev-help@struts.apache.org
> >>>
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by James Mitchell <jm...@apache.org>.
Sorry if I'm piping up late on this.
What's the plans for Tiles? Will we support embedded tiles or will
we simply adapt standalone to work as we do for the commons stuff?
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: jmitchell@apache.org
Skype: jmitchtx
On Aug 25, 2005, at 1:00 AM, Craig McClanahan wrote:
> On 8/24/05, Martin Cooper <mf...@gmail.com> wrote:
>
>> On 8/24/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
>>
>>> From: <gr...@intellicare.com> (on struts-user)
>>>
>>>> test.jsp has this:
>>>> <%@ taglib uri="http://jakarta.apache.org/tiles" prefix="tiles" %>
>>>>
>>>
>>> Jakarta? That can't be right... there's a problem:
>>>
>>> The tld in last night's tiles-core.jar has a JSP 1.1 tld with
>>> that uri,
>>> which is coming from src/conf.
>>>
>>> I noticed that tld the other day when I was changing the Maven
>>> build files.
>>> The doc/userGuide/tiles-core.xml file does have the right uri. I
>>> think the
>>> one in src/conf needs to be deleted-- the tld is probably still
>>> supposed to
>>> be generated from the files under doc/userGuide and doc/
>>> stylesheets as part
>>> of the build.
>>>
>>> Eventually I'll generate a complete tld with all the
>>> documentation, so that
>>> Maven can create the taglibdoc and tag reference pages... the one in
>>> src/conf doesn't have any of that.
>>>
>>> And what JSP version is Standalone Tiles using? The build files
>>> declare a
>>> dependency on Servlet 2.4 and JSP 2.0. I thought the intent was
>>> for Struts
>>> Classic (which is now at Servlet 2.3) to move to Standalone
>>> Tiles. Is that
>>> going to be possible with the mismatch in dependencies?
>>>
>>
>> I believe the intent was that Standalone Tiles should rely on
>> Servlets
>> 2.3 and JSP 1.2, as does Struts Classic. I hope that's still the
>> case,
>> and that we just need to fix up Tiles to conform to that.
>>
>>
>
> Yes, that was definitely the intent for Standalone Tiles. It probably
> got mixed up during the multiple iterations of cut-n-paste from the
> Struts-embedded sources, plus cut-n-paste changes to the build
> environment, plus ...
>
> Craig
>
>
>> --
>> Martin Cooper
>>
>>
>>
>>> --
>>> Wendy
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Craig McClanahan" <cr...@gmail.com>
On 8/24/05, Martin Cooper <mf...@gmail.com> wrote:
>> I believe the intent was that Standalone Tiles should rely on Servlets
>> 2.3 and JSP 1.2, as does Struts Classic. I hope that's still the case,
>> and that we just need to fix up Tiles to conform to that.
> Yes, that was definitely the intent for Standalone Tiles.
The build files have been changed to Servlet 2.3/JSP 1.2.
Looking at the URI again, I assume http://jakarta.apache.org/tiles *is* the
correct one, since the URI in the doc/userGuide file still has 'struts', and
there is nothing in build.xml that's generating the tld from the userGuide.
I'll get the documentation into tiles-core.tld before deleting the old
doc/userGuide/struts-tiles.xml and associated stylesheet, so that one day
Maven can build the Tiles website.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/24/05, Martin Cooper <mf...@gmail.com> wrote:
> On 8/24/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> > From: <gr...@intellicare.com> (on struts-user)
> > > test.jsp has this:
> > > <%@ taglib uri="http://jakarta.apache.org/tiles" prefix="tiles" %>
> >
> > Jakarta? That can't be right... there's a problem:
> >
> > The tld in last night's tiles-core.jar has a JSP 1.1 tld with that uri,
> > which is coming from src/conf.
> >
> > I noticed that tld the other day when I was changing the Maven build files.
> > The doc/userGuide/tiles-core.xml file does have the right uri. I think the
> > one in src/conf needs to be deleted-- the tld is probably still supposed to
> > be generated from the files under doc/userGuide and doc/stylesheets as part
> > of the build.
> >
> > Eventually I'll generate a complete tld with all the documentation, so that
> > Maven can create the taglibdoc and tag reference pages... the one in
> > src/conf doesn't have any of that.
> >
> > And what JSP version is Standalone Tiles using? The build files declare a
> > dependency on Servlet 2.4 and JSP 2.0. I thought the intent was for Struts
> > Classic (which is now at Servlet 2.3) to move to Standalone Tiles. Is that
> > going to be possible with the mismatch in dependencies?
>
> I believe the intent was that Standalone Tiles should rely on Servlets
> 2.3 and JSP 1.2, as does Struts Classic. I hope that's still the case,
> and that we just need to fix up Tiles to conform to that.
>
Yes, that was definitely the intent for Standalone Tiles. It probably
got mixed up during the multiple iterations of cut-n-paste from the
Struts-embedded sources, plus cut-n-paste changes to the build
environment, plus ...
Craig
> --
> Martin Cooper
>
>
> > --
> > Wendy
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Standalone Tiles - JSP version & tld file
Posted by Martin Cooper <mf...@gmail.com>.
On 8/24/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> From: <gr...@intellicare.com> (on struts-user)
> > test.jsp has this:
> > <%@ taglib uri="http://jakarta.apache.org/tiles" prefix="tiles" %>
>
> Jakarta? That can't be right... there's a problem:
>
> The tld in last night's tiles-core.jar has a JSP 1.1 tld with that uri,
> which is coming from src/conf.
>
> I noticed that tld the other day when I was changing the Maven build files.
> The doc/userGuide/tiles-core.xml file does have the right uri. I think the
> one in src/conf needs to be deleted-- the tld is probably still supposed to
> be generated from the files under doc/userGuide and doc/stylesheets as part
> of the build.
>
> Eventually I'll generate a complete tld with all the documentation, so that
> Maven can create the taglibdoc and tag reference pages... the one in
> src/conf doesn't have any of that.
>
> And what JSP version is Standalone Tiles using? The build files declare a
> dependency on Servlet 2.4 and JSP 2.0. I thought the intent was for Struts
> Classic (which is now at Servlet 2.3) to move to Standalone Tiles. Is that
> going to be possible with the mismatch in dependencies?
I believe the intent was that Standalone Tiles should rely on Servlets
2.3 and JSP 1.2, as does Struts Classic. I hope that's still the case,
and that we just need to fix up Tiles to conform to that.
--
Martin Cooper
> --
> Wendy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Standalone Tiles - JSP version & tld file
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: <gr...@intellicare.com> (on struts-user)
> test.jsp has this:
> <%@ taglib uri="http://jakarta.apache.org/tiles" prefix="tiles" %>
Jakarta? That can't be right... there's a problem:
The tld in last night's tiles-core.jar has a JSP 1.1 tld with that uri,
which is coming from src/conf.
I noticed that tld the other day when I was changing the Maven build files.
The doc/userGuide/tiles-core.xml file does have the right uri. I think the
one in src/conf needs to be deleted-- the tld is probably still supposed to
be generated from the files under doc/userGuide and doc/stylesheets as part
of the build.
Eventually I'll generate a complete tld with all the documentation, so that
Maven can create the taglibdoc and tag reference pages... the one in
src/conf doesn't have any of that.
And what JSP version is Standalone Tiles using? The build files declare a
dependency on Servlet 2.4 and JSP 2.0. I thought the intent was for Struts
Classic (which is now at Servlet 2.3) to move to Standalone Tiles. Is that
going to be possible with the mismatch in dependencies?
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Shale and Tiles integration - where oh where is shale-tiles.jar?
Posted by Greg Reddin <gr...@fnf.com>.
gramani@intellicare.com wrote:
> root cause
> java.lang.NoSuchMethodError:
> org.apache.tiles.DefinitionsFactory.getDefinition(Ljava/lang/String;Ljav
> ax/servlet/ServletRequest;Ljavax/servlet/ServletContext;)Lorg/apache/til
> es/ComponentDefinition;
Ok, now you're into the place where Tiles changes have been made but
Shale changes have not kept up yet. The Tiles API has changed and David
is working on changes to the TilesViewHandler to integrate those Tiles
changes.
I just checked and David's changes have been checked into svn. If you
could build Shale from source you'd get the changes. Or if you could
replace TilesViewHandler with one that has the following getTile()
method you'll get past this error. Alternatively you can wait till
tomorrow and download tonight's nightly build.
/**
* <p>Looks up a tile, given a name. If the tile does not exist, and the
* <code>name</code> begins with a slash ('/'), look for a tile
* without the slash. If no tile is found, return <code>null</code>.</p>
*
* @param name The tile to lookup
*/
private ComponentDefinition getTile(String name) {
if (name == null)
return null;
ExternalContext externalContext = FacesContext.getCurrentInstance()
.getExternalContext();
ServletRequest request =
(ServletRequest)externalContext.getRequest();
ServletContext servletContext = (ServletContext)externalContext.
getContext();
ComponentDefinition tile = null;
try {
tile = TilesUtil.getDefinition(name, request, servletContext);
}
catch(NoSuchDefinitionException nsex) { /* not here */ }
catch(DefinitionsFactoryException dex) { /* not here */ }
if (tile == null && name.startsWith("/")) { // try again w/o slash...
try {
tile = TilesUtil.getDefinition(name, request, servletContext);
}
catch(NoSuchDefinitionException nsdex) { /* not here */ }
catch(DefinitionsFactoryException dfex) { /* not here */ }
}
return tile;
}
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Shale and Tiles integration - where oh where is shale-tiles.jar?
Posted by gr...@intellicare.com.
Greg Reddin <gr...@fnf.com> wrote on 08/24/2005 01:50:23 PM:
> gramani@intellicare.com wrote:
> > now after a bit of fumbling, I get the following error:
> >
> > javax.servlet.ServletException: Can't get definitions factory from
> > context.
>
> Do you have TilesServlet configured in your web.xml? If it's not
> configured the Tiles Definitions won't be loaded at startup.
Greg, I was trying just that when you note came in. So now my web.xml has
this:
<servlet>
<servlet-name>tiles</servlet-name>
<servlet-class>org.apache.tiles.servlets.TilesServlet</
servlet-class>
<init-param>
<param-name>definitions-config</param-name>
<param-value>/WEB-INF/tiles.xml</param-value>
</init-param>
<load-on-startup>2</load-on-startup>
</servlet>
(FacesServlet has the load-on-startup as 1)
Ok, so I guess I'm past the defintions factory not found error but I now
have this one:
javax.servlet.ServletException: Servlet execution threw an exception
org.apache.jasper.runtime.PageContextImpl.doForward(PageContextImpl.java:693)
org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:660)
org.apache.jsp.index_jsp._jspService(org.apache.jsp.index_jsp:43)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:291)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
org.apache.shale.faces.InvokeCommand.execute(InvokeCommand.java:40)
org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:166)
org.apache.shale.faces.ShaleApplicationFilter.doFilter(ShaleApplicationFilter.java:252)
root cause
java.lang.NoSuchMethodError:
org.apache.tiles.DefinitionsFactory.getDefinition(Ljava/lang/String;Ljavax/servlet/ServletRequest;Ljavax/servlet/ServletContext;)Lorg/apache/tiles/ComponentDefinition;
org.apache.shale.tiles.TilesViewHandler.getTile(TilesViewHandler.java:274)
org.apache.shale.tiles.TilesViewHandler.renderView(TilesViewHandler.java:135)
org.apache.shale.faces.ShaleViewHandler.renderView(ShaleViewHandler.java:142)
org.apache.shale.clay.faces.ClayViewHandler.renderView(ClayViewHandler.java:240)
com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:87)
com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:200)
com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:117)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:198)
org.apache.jasper.runtime.PageContextImpl.doForward(PageContextImpl.java:693)
org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:660)
org.apache.jsp.index_jsp._jspService(org.apache.jsp.index_jsp:43)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:291)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
org.apache.shale.faces.InvokeCommand.execute(InvokeCommand.java:40)
org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:166)
org.apache.shale.faces.ShaleApplicationFilter.doFilter(ShaleApplicationFilter.java:252)
>
> Greg
>
Maybe it is time to follow your advice and stop working on this..?
Thanks for your time!
Geeta
Re: Shale and Tiles integration - where oh where is shale-tiles.jar?
Posted by Greg Reddin <gr...@fnf.com>.
gramani@intellicare.com wrote:
> now after a bit of fumbling, I get the following error:
>
> javax.servlet.ServletException: Can't get definitions factory from
> context.
Do you have TilesServlet configured in your web.xml? If it's not
configured the Tiles Definitions won't be loaded at startup.
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Shale and Tiles integration - where oh where is shale-tiles.jar?
Posted by gr...@intellicare.com.
Wendy Smoak <ja...@wendysmoak.com> wrote on 08/24/2005 01:35:38 PM:
> From: <gr...@intellicare.com>
>
> > test.jsp has this:
> > <%@ taglib uri="http://jakarta.apache.org/tiles" prefix="tiles" %>
>
> Geeta, that caught my eye because it's not the right uri for Standalone
> Tiles. It looks like there might be a problem with the build files--
the
> wrong tld is getting included in tiles-core.jar. I'm not sure if that's
> actually causing your problem, but I'm taking that issue over to the dev
> list for discussion.
Wendy, thank you for your note! Well, tell you the truth I am not at all
sure any more where I got that url. All I know is that this url at least
exists, wheras some of the others I found while I was searching for clues
gave me a 404!
> --
> Wendy Smoak
Thanks again!
Geeta
Re: Shale and Tiles integration - where oh where is shale-tiles.jar?
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: <gr...@intellicare.com>
> test.jsp has this:
> <%@ taglib uri="http://jakarta.apache.org/tiles" prefix="tiles" %>
Geeta, that caught my eye because it's not the right uri for Standalone
Tiles. It looks like there might be a problem with the build files-- the
wrong tld is getting included in tiles-core.jar. I'm not sure if that's
actually causing your problem, but I'm taking that issue over to the dev
list for discussion.
--
Wendy Smoak
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Shale and Tiles integration - where oh where is shale-tiles.jar?
Posted by gr...@intellicare.com.
Craig McClanahan <cr...@gmail.com> wrote on 08/24/2005 12:55:18 PM:
>
> Besides being bundled inside the example webapp, nightly builds of
> standalone tiles are available too:
>
> http://cvs.apache.org/builds/struts/nightly/sandbox/tiles-core/
>
Yes, thank you Craig, I did manage to find that. After Greg's note (only
perhaps a few thousand down in your in-box) I promised myself I'd shelve
the shale-tiles integration till later. But I couldn't help myself...;) So
now after a bit of fumbling, I get the following error:
javax.servlet.ServletException: Can't get definitions factory from
context.
I googled on this error and seems like people are talking about
struts-config.xml (oh, how dated can you get..;)). I have a feeling I'm
*really* close.. but of course may be totally wrong.. (:(
fyi, my faces-config has:
<application>
<!-- Tiles Integration -->
<view-handler>
org.apache.shale.tiles.TilesViewHandler
</view-handler>
</application>
tiles-def.xml has this:
<definition name="/login" path="/layout/layout.jsp">
<put name="title" value="Intellicare, Inc." />
<put name="header" value="/layout/header.jsp" />
<put name="navigation" value="/layout/navigation.jsp" />
<put name="content" value="/layout/content.jsp"/>
</definition>
test.jsp has this:
<%@ taglib uri="http://jakarta.apache.org/tiles" prefix="tiles" %>
<tiles:insert definition="/login">
</tiles:insert>
and index.jsp forwards to test.faces
> Craig
>
Thanks yet again,
Geeta
Re: Shale and Tiles integration - where oh where is shale-tiles.jar?
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/24/05, gramani@intellicare.com <gr...@intellicare.com> wrote:
> Hi again,
>
> So now that I have a trivial login page working, I want to integrate tiles
> in..:) I found this link:
>
> http://jroller.com/page/dgeary?entry=shale_adds_tiles_integration
>
> which seems pretty promising. But there's mention of a shale-tiles.jar but
> no word about where to download it..? Googling for it brought no joy
> either...(:( Some other place (I forget where, I've been so all over..)
> said something about a standalone tiles which I did find (but that's
> called tiles.core)..
>
> So.. (sigh..) I have to ask for help again.. thanks once again in advance!
> Geeta
>
Besides being bundled inside the example webapp, nightly builds of
standalone tiles are available too:
http://cvs.apache.org/builds/struts/nightly/sandbox/tiles-core/
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Shale and Tiles integration - where oh where is shale-tiles.jar?
Posted by gr...@intellicare.com.
Greg Reddin <gr...@fnf.com> wrote on 08/24/2005 12:01:06 PM:
>
> The internals of Tiles have been dramatically changed in the last week
> and just yesterday David was working on changes to the Shale
> integration. I'm not sure if those changes are complete and checked in
> yet. So if you can wait a couple of days integration might be back.
Greg, thanks for the info! If an announcement were made in this list about
"completion" of this and/or other features that would be really cool! :)
>
> Greg
>
Geeta
Re: Shale and Tiles integration - where oh where is shale-tiles.jar?
Posted by Greg Reddin <gr...@fnf.com>.
gramani@intellicare.com wrote:
> I wondered about that actually. I mean I know shale is still evolving
> and
> what not and seems like the shale-tiles.jar was created only like last
> month or something, but in any case, if using it needed the tiles
> standalone jar, why wasn't it (the tiles jar) bundled in the
> struts-shale-core lib directory too..? David Geary (the chap who did the
>
> integration) surely would have needed that jar so why not include it in
> for us poor slobs too?.. Life in the bleeding edge sure isn't too
> comfortable..!
The internals of Tiles have been dramatically changed in the last week
and just yesterday David was working on changes to the Shale
integration. I'm not sure if those changes are complete and checked in
yet. So if you can wait a couple of days integration might be back.
When I first downloaded Shale I ran into the same problem with not being
able to find the standalone Tiles jar. I never figured out what to do
about it. I bet David and others found a workaround by manually copying
the jars over or something.
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Shale and Tiles integration - where oh where is shale-tiles.jar?
Posted by gr...@intellicare.com.
Greg Reddin <gr...@fnf.com> wrote on 08/24/2005 11:36:39 AM:
> Probably not :-) I think the main problem is that shale and standalone
> tiles are both still evolving. I downloaded a build of shale about a
> month ago and it's so out of date I'm not even trying to use it anymore.
Yeah. I have the August 23rd build and am wondering if I'm out of date..;)
> The biggest issue with integration is that Standalone Tiles is still a
> sandbox project. Because of this its future and direction are still
> undetermined. I hope the stability needed to determine where it will
> live will be acheived very soon. Once that's figured out integration
> with Shale shouldn't be that big a deal.
>
> It's not really an issue of code integration as much as "build"
> integration -- trying to figure out where the library is and whatnot.
I wondered about that actually. I mean I know shale is still evolving and
what not and seems like the shale-tiles.jar was created only like last
month or something, but in any case, if using it needed the tiles
standalone jar, why wasn't it (the tiles jar) bundled in the
struts-shale-core lib directory too..? David Geary (the chap who did the
integration) surely would have needed that jar so why not include it in
for us poor slobs too?.. Life in the bleeding edge sure isn't too
comfortable..!
>
> Greg
>
Geeta
Re: Shale and Tiles integration - where oh where is shale-tiles.jar?
Posted by Greg Reddin <gr...@fnf.com>.
gramani@intellicare.com wrote:
> I don't think Tiles integration ought to be
> difficult, right..?.. [..falls over laughing..]
Probably not :-) I think the main problem is that shale and standalone
tiles are both still evolving. I downloaded a build of shale about a
month ago and it's so out of date I'm not even trying to use it anymore.
The biggest issue with integration is that Standalone Tiles is still a
sandbox project. Because of this its future and direction are still
undetermined. I hope the stability needed to determine where it will
live will be acheived very soon. Once that's figured out integration
with Shale shouldn't be that big a deal.
It's not really an issue of code integration as much as "build"
integration -- trying to figure out where the library is and whatnot.
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Shale and Tiles integration - where oh where is shale-tiles.jar?
Posted by gr...@intellicare.com.
Rick Reumann <st...@reumann.net> wrote on 08/24/2005 11:30:55 AM:
> gramani@intellicare.com wrote the following on 8/24/2005 10:45 AM:
>
> > Btw, if anyone has successfully got tiles to work with shale, could
you
> > please share your code? If I manage to do this I shall write this up
so it
> > may help soembody else.. I don't think Tiles integration ought to be
> > difficult, right..?.. [..falls over laughing..]
>
> I'm finding it difficult, so please I'd love to see your code when
> you're done.
*Not* what i was hoping to hear..! But sure, I'll let you know what, if
anything, I can get to work!
> --
> Rick
Geeta
Re: Shale and Tiles integration - where oh where is shale-tiles.jar?
Posted by Rick Reumann <st...@reumann.net>.
gramani@intellicare.com wrote the following on 8/24/2005 10:45 AM:
> Btw, if anyone has successfully got tiles to work with shale, could you
> please share your code? If I manage to do this I shall write this up so it
> may help soembody else.. I don't think Tiles integration ought to be
> difficult, right..?.. [..falls over laughing..]
I'm finding it difficult, so please I'd love to see your code when
you're done.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Shale and Tiles integration - where oh where is shale-tiles.jar?
Posted by gr...@intellicare.com.
Hi Martin, that's just the tiles.jar, right? I needed the
shale-tiles.jar.. which I found within struts-shale-core-library/lib in
the latest cvs download.. (I'm not being ambitious just yet - so I'm not
building from source, just trying to use the jar files will do for
now..;))
Btw, in case anybody else is struggling with this too..
David Geary says in his web log:
http://jroller.com/page/dgeary?entry=shale_adds_tiles_integration that the
shale-tiles.jar "has a META-INF/web.xml that declares a Tiles view
handler. ".. But I think he means to say faces-config.xml (not web.xml)..
Anyway, I have added that notation about the TilesViewHandler into my
faces-config.xml and who knows, maybe something will work..;)
Btw, if anyone has successfully got tiles to work with shale, could you
please share your code? If I manage to do this I shall write this up so it
may help soembody else.. I don't think Tiles integration ought to be
difficult, right..?.. [..falls over laughing..]
Geeta
"Martin Gainty" <mg...@hotmail.com> wrote on 08/24/2005 10:31:48 AM:
> Geeta
> Did you try downloading from Cedric DuMoulins site?
> http://www.lifl.fr/~dumoulin/tiles/doc/download.html
> Martin-
> ----- Original Message -----
> From: <gr...@intellicare.com>
> To: "Struts Users Mailing List" <us...@struts.apache.org>
> Sent: Wednesday, August 24, 2005 10:04 AM
> Subject: Shale and Tiles integration - where oh where is
shale-tiles.jar?
>
>
> > Hi again,
> >
> > So now that I have a trivial login page working, I want to integrate
tiles
> > in..:) I found this link:
> >
> > http://jroller.com/page/dgeary?entry=shale_adds_tiles_integration
> >
> > which seems pretty promising. But there's mention of a shale-tiles.jar
but
> > no word about where to download it..? Googling for it brought no joy
> > either...(:( Some other place (I forget where, I've been so all
over..)
> > said something about a standalone tiles which I did find (but that's
> > called tiles.core)..
> >
> > So.. (sigh..) I have to ask for help again.. thanks once again in
advance!
> > Geeta
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
> CONFIDENTIALITY NOTICE:This email is intended solely for the person
> or entity to which it is addressed and may contain confidential
> and/or protected health information. Any duplication,
> dissemination, action taken in reliance upon, or other use of this
> information by persons or entities other than the intended recipient
> is prohibited and may violate applicable laws. If this email has
> been received in error, please notify the sender and delete the
> information from your system. The views expressed in this email are
> those of the sender and may not necessarily represent the views of
> IntelliCare.
Re: Shale and Tiles integration - where oh where is shale-tiles.jar?
Posted by Martin Gainty <mg...@hotmail.com>.
I did'nt realise he wanted the nightly build
I was 'error'ing on the side of the released (builds without errors and has
passed unit, integration and regression test) package
Caveat emptor
Martin
----- Original Message -----
From: "David G. Friedman" <hu...@ix.netcom.com>
To: "Struts Users Mailing List" <us...@struts.apache.org>
Sent: Wednesday, August 24, 2005 10:48 AM
Subject: RE: Shale and Tiles integration - where oh where is
shale-tiles.jar?
> Martin,
>
> Would that download even work? I followed your link and
> it mentions it is from 2002. Doesn't Shale with tiles
> REQUIRE the tiles standalone distribution in the 1.3 trunk
> or nightly build?
>
> I think you'll need the tiles-core from the tiles nightly
> build:
> http://svn.apache.org/builds/struts/nightly/sandbox/tiles-core/
>
> And the shale-tiles.jar from the Shale core nightly build since
> it has the ViewHandler class with a META-INF/faces-config.xml
> autoloading file in it:
>
> http://svn.apache.org/builds/struts/nightly/struts-shale/core-library/
>
> Regards,
> David
>
> -----Original Message-----
> From: Martin Gainty [mailto:mgainty@hotmail.com]
> Sent: Wednesday, August 24, 2005 10:32 AM
> To: Struts Users Mailing List
> Subject: Re: Shale and Tiles integration - where oh where is
> shale-tiles.jar?
>
>
> Geeta
> Did you try downloading from Cedric DuMoulins site?
> http://www.lifl.fr/~dumoulin/tiles/doc/download.html
> Martin-
> ----- Original Message -----
> From: <gr...@intellicare.com>
> To: "Struts Users Mailing List" <us...@struts.apache.org>
> Sent: Wednesday, August 24, 2005 10:04 AM
> Subject: Shale and Tiles integration - where oh where is shale-tiles.jar?
>
>
>> Hi again,
>>
>> So now that I have a trivial login page working, I want to integrate
>> tiles
>> in..:) I found this link:
>>
>> http://jroller.com/page/dgeary?entry=shale_adds_tiles_integration
>>
>> which seems pretty promising. But there's mention of a shale-tiles.jar
>> but
>> no word about where to download it..? Googling for it brought no joy
>> either...(:( Some other place (I forget where, I've been so all over..)
>> said something about a standalone tiles which I did find (but that's
>> called tiles.core)..
>>
>> So.. (sigh..) I have to ask for help again.. thanks once again in
>> advance!
>> Geeta
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: Shale and Tiles integration - where oh where is shale-tiles.jar?
Posted by "David G. Friedman" <hu...@ix.netcom.com>.
Martin,
Would that download even work? I followed your link and
it mentions it is from 2002. Doesn't Shale with tiles
REQUIRE the tiles standalone distribution in the 1.3 trunk
or nightly build?
I think you'll need the tiles-core from the tiles nightly
build:
http://svn.apache.org/builds/struts/nightly/sandbox/tiles-core/
And the shale-tiles.jar from the Shale core nightly build since
it has the ViewHandler class with a META-INF/faces-config.xml
autoloading file in it:
http://svn.apache.org/builds/struts/nightly/struts-shale/core-library/
Regards,
David
-----Original Message-----
From: Martin Gainty [mailto:mgainty@hotmail.com]
Sent: Wednesday, August 24, 2005 10:32 AM
To: Struts Users Mailing List
Subject: Re: Shale and Tiles integration - where oh where is
shale-tiles.jar?
Geeta
Did you try downloading from Cedric DuMoulins site?
http://www.lifl.fr/~dumoulin/tiles/doc/download.html
Martin-
----- Original Message -----
From: <gr...@intellicare.com>
To: "Struts Users Mailing List" <us...@struts.apache.org>
Sent: Wednesday, August 24, 2005 10:04 AM
Subject: Shale and Tiles integration - where oh where is shale-tiles.jar?
> Hi again,
>
> So now that I have a trivial login page working, I want to integrate tiles
> in..:) I found this link:
>
> http://jroller.com/page/dgeary?entry=shale_adds_tiles_integration
>
> which seems pretty promising. But there's mention of a shale-tiles.jar but
> no word about where to download it..? Googling for it brought no joy
> either...(:( Some other place (I forget where, I've been so all over..)
> said something about a standalone tiles which I did find (but that's
> called tiles.core)..
>
> So.. (sigh..) I have to ask for help again.. thanks once again in advance!
> Geeta
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Shale and Tiles integration - where oh where is shale-tiles.jar?
Posted by Martin Gainty <mg...@hotmail.com>.
Geeta
Did you try downloading from Cedric DuMoulins site?
http://www.lifl.fr/~dumoulin/tiles/doc/download.html
Martin-
----- Original Message -----
From: <gr...@intellicare.com>
To: "Struts Users Mailing List" <us...@struts.apache.org>
Sent: Wednesday, August 24, 2005 10:04 AM
Subject: Shale and Tiles integration - where oh where is shale-tiles.jar?
> Hi again,
>
> So now that I have a trivial login page working, I want to integrate tiles
> in..:) I found this link:
>
> http://jroller.com/page/dgeary?entry=shale_adds_tiles_integration
>
> which seems pretty promising. But there's mention of a shale-tiles.jar but
> no word about where to download it..? Googling for it brought no joy
> either...(:( Some other place (I forget where, I've been so all over..)
> said something about a standalone tiles which I did find (but that's
> called tiles.core)..
>
> So.. (sigh..) I have to ask for help again.. thanks once again in advance!
> Geeta
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Shale and Tiles integration - where oh where is shale-tiles.jar?
Posted by gr...@intellicare.com.
oops, sorry, please ignore this note.. My bad.. The jar is bundled right
into the struts-shale core library in the latest build..). Sorry for
wasting your time.
Geeta
gramani@intellicare.com wrote on 08/24/2005 10:04:06 AM:
> Hi again,
>
> So now that I have a trivial login page working, I want to integrate
tiles
> in..:) I found this link:
>
> http://jroller.com/page/dgeary?entry=shale_adds_tiles_integration
>
> which seems pretty promising. But there's mention of a shale-tiles.jar
but
> no word about where to download it..? Googling for it brought no joy
> either...(:( Some other place (I forget where, I've been so all over..)
> said something about a standalone tiles which I did find (but that's
> called tiles.core)..
>
> So.. (sigh..) I have to ask for help again.. thanks once again in
advance!
> Geeta
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
> CONFIDENTIALITY NOTICE:This email is intended solely for the person
> or entity to which it is addressed and may contain confidential
> and/or protected health information. Any duplication,
> dissemination, action taken in reliance upon, or other use of this
> information by persons or entities other than the intended recipient
> is prohibited and may violate applicable laws. If this email has
> been received in error, please notify the sender and delete the
> information from your system. The views expressed in this email are
> those of the sender and may not necessarily represent the views of
> IntelliCare.