On 10/4/05, Leon Rosenberg <[EMAIL PROTECTED]> wrote:
>
> On 10/4/05, Greg Reddin <[EMAIL PROTECTED]> wrote:
> > On Oct 4, 2005, at 3:55 AM, Leon Rosenberg wrote:
> > >
> > > That's another interesting question, if JSF is all-component, what do
> > > I need tiles for? I mean Tiles was cool to define a common renderer
> > > for an abstract view-component which was then implicitely defined with
> > > struts-classic. Now JSF supports component-rendering which should make
> > > Tiles obsolete. What would I need Tiles for then? Or do I miss
> > > something (as usual)? :-)
> >
> > In my limited experience with JSF it does not seem to contain
> > templating capabilities. So in Struts classic I would use Tiles for
> > creating site templates as well as reusable views (or component-based
> > views). But with JSF Tiles still proves useful for templating and
> > for further breaking up view components into smaller reusable
> > pieces. But, honestly, I have yet to use the two together simply
> > because I haven't built a real app on JSF yet. So much of my view is
> > based on conceptual thinking and not real world experience.
>
> Maybe I'm misunderstanding the concept completely, but I thought JSF
> goal would be to create a component structure (tree) which allows
> itself to be rendered with a special rendering kit to anything. So in
> case I have template-able html (or whatever) code, I define a new
> component, which manages exactly this piece of resulting code and
> provide a renderer for it. What am i getting false?


Traditional techniques for layout reuse (Tiles, SiteMesh, etc.) continue to
be usable with JSF ... it's just that you now have the additional option to
have components to manage the layout for you as well. As a toy example, I
once built myself a component that does the equivalent of Swing's
BorderLayout (components you insert inside have an affinity for one
particular edge, or the center, of the rectangle rendered by that
component). This sort of approach leverages the fact that JSF components are
in fact organized into a tree ... and, components that *want* to can take
responsibility for rendering their children, instead of letting those
components simply render themselves.

>
> > Greg
>
> Leon


Craig

Reply via email to