On Thu, Oct 05, 2000 at 05:36:46PM -0400, Geir Magnusson Jr. wrote:
> Olivier [SMTP:[EMAIL PROTECTED]] wrote :
>
> I don't like this because you hope and pray that template2 closes things up
> right with </body></html>. I hope that you don't indend to open a <table>
> in 1 and close it in 2. Yeek.
>
> As another example, I have a similar need in a site I am building I use
> parse to have a 'skin' frame in an app that does site hosting -> the
> controller servlet chooses the appropriate skin that was selected by the
> site owner/administrator, and then chooses the appropriate 'mainbody'
> template, which is a borderless, navless, footerless view on whatever data
> is to be shown and puts that into the context [ context.put("mainbody",
> strMainbodyTemplate ) ] and then stuffs any needed data for that mainbody
> template into the context The mainbody frames wouldn't generate a
> complete page by themselves. They have to 'live' in a frame, but they don't
> care where. That's up to the frame designer. The frame :
>
> <html>
> <body>
>
> Welcome to Blarght Blargh (header stuff)
>
> <table>
> <tr>
> <td>
> leftside navigational junk, usually dynamic from db
> </td>
> <td>
> #parse $mainbody
> </td>
> <td>
> rightside commerce store callouts, from db
> </td>
> </tr>
> </table>
> footer stuff
> </body>
> </html>
>
>
Thanks Geir,
I am doing similar things. Also what you describe works fine it does not
seems the most logical to me.
I guest what you have is a structure with two objects: the main page
object and a Body object. Each of these objects (I guess) have some
logic to decide which template should be use to serve a particular
request, the main one decide which layout to use and the body which
content to serve.
However with Velocity when the 'main Page' object call template 1, there
is no way to give back the control to the 'body' object.
To work around this what you do is to determine everything before
hand: before the first call to template1 and all the hierarchy of nested
templates and data.
Which means that you add to the context all the template names and
data which are going to be used by the nested #parse calls.
This is ok if you have one nested object but become very messy if
you have 5 or 6 levels of depth.
Something like:
Page
Body
Layout
Latest news container
News item 1
Author 1
Author 2
News item 2
Author 3
One way around this would be the ability to set some sort of break
points in a template. So, the 'main page' object could call the
'merge' method to render a template from the start to the first break
point, then the control would return back to the 'main page' object
which could let the 'body' object insert futher templates or data ,
then finally re-enter template 1 and render from the break-point to
the end.
My original question was: do you have, yes or no, interest in the
notion of a break-point system to do partial rendering from points to
points in a template, so that an external traversing object could
control the nesting.
The answer is obviously No! That's fine, no worries!
I don't fully understand why some guy has to become excited and mix up
hamburger recipies in the sauce!?
Regards.
Olivier.
----------------------------------------------------------------------
Olivier Louchart-Fletcher
Email: [EMAIL PROTECTED]
