Abstracting JSF presentation from HTML?

[Simon Kitching <sk...@obsidium.com>]

Korhonen, Kalle wrote:
>> -----Original Message-----
>> From: Adam Winer [mailto:awiner@gmail.com] 
>> Sent: Thursday, December 15, 2005 11:23 AM
>> Subject: Re: svn commit: r356552 - in 
>> Hope I'm not coming off as insulting any of the committers 
>> here.  Especially 'cause I *totally* agree that abstracting 
>> away from HTML is the only way to go.  I'm just reacting with 
> 
> Adam, care to elaborate more on why you think abstracting away from HTML
> is the only way to go? I.e. why not Tapestry-like approach (though I
> guess you could see jwcid as abstracting away from HTML too)?
> 

Well one obvious reason is to be able to render to different 
presentation technologies. HTML is definitely *not* a perfect 
presentation language that will last us into the next century :-).

If the presentation is done in terms of widgets, eg by specifying a 
"selectOneMenu" rather than a <SELECT> then this can be rendered as 
HTML, or as Mozilla-XUL or any other presentation markup that may be 
invented in the future.

There are of course disadvantages to this too, particularly when JSF is 
in as raw a state as currently. Often it is necessary to mix JSF and 
HTML to get the necessary results, and the more abstract the JSF 
presentation markup is the harder it is to do this. And using CSS for 
presentation is simple when using a tapestry-like approach, but much 
less so when using an "abstract" JSF view definition.

Regards,

Simon

Re: Abstracting JSF presentation from HTML?

[Adam Winer <aw...@gmail.com>]

Jacob and Simon have basically said what I would have said
(and better).  But I'll write on, anyway. :)

When I say it's "the only way to go", that's hyperbolic.  There
are, of course, two ways to go.  You can focus on the HTML
world, or you can focus on the component world.  The primary
reason I hear for focusing on HTML is not that is technically
better - it's that "Our webpage designers work in DreamWeaver,
etc., etc.".  That argument is inherently one of what is,
not what *should be*.

HTML-centric development can really only take us so far;
but it's reaching its breaking point as the overall client-side
stack gets more and more complicated - AJAX, SVG, XUL,
CSS 2+3 (*not* simple specs!) etc., all making the once-simple
job of markup more and more nightmarish for the average
designer.

Reusable components are "the way out".  Component-centric
development processes have more legs - far more
future-proofing - than markup-centric development processes.

One final note:   there's lots we need to do from the JSF side of things
to make this really work, like:

  - Easier-to-write components/renderers
  - More robust support for mixing component libraries
  - Better support for more "talky" protocols like XmlHttp

JSF in its current form is a pretty good start, but it ain't all
the way there yet.

-- Adam


On 12/21/05, Jacob Hookom <ja...@hookom.net> wrote:
> I have written quite a bit on this topic in relation to components and
> CSS/XUL and the benefits of structual separation with components:
>
> http://weblogs.java.net/blog/jhook/archive/2005/07/programmer_frie_1.html
>
> Facelets ability to work with any markup (XUL included) and allowing
> custom compositions (UserTags) allows a great degree of flexability and
> re-use with JSF.
>
> -- Jacob
>
> Simon Kitching wrote:
>
> > Korhonen, Kalle wrote:
> >
> >>> -----Original Message-----
> >>> From: Adam Winer [mailto:awiner@gmail.com] Sent: Thursday, December
> >>> 15, 2005 11:23 AM
> >>> Subject: Re: svn commit: r356552 - in Hope I'm not coming off as
> >>> insulting any of the committers here.  Especially 'cause I *totally*
> >>> agree that abstracting away from HTML is the only way to go.  I'm
> >>> just reacting with
> >>
> >>
> >> Adam, care to elaborate more on why you think abstracting away from HTML
> >> is the only way to go? I.e. why not Tapestry-like approach (though I
> >> guess you could see jwcid as abstracting away from HTML too)?
> >>
> >
> > Well one obvious reason is to be able to render to different
> > presentation technologies. HTML is definitely *not* a perfect
> > presentation language that will last us into the next century :-).
> >
> > If the presentation is done in terms of widgets, eg by specifying a
> > "selectOneMenu" rather than a <SELECT> then this can be rendered as
> > HTML, or as Mozilla-XUL or any other presentation markup that may be
> > invented in the future.
> >
> > There are of course disadvantages to this too, particularly when JSF
> > is in as raw a state as currently. Often it is necessary to mix JSF
> > and HTML to get the necessary results, and the more abstract the JSF
> > presentation markup is the harder it is to do this. And using CSS for
> > presentation is simple when using a tapestry-like approach, but much
> > less so when using an "abstract" JSF view definition.
> >
> > Regards,
> >
> > Simon
> >
>
>
> --
> Jacob Hookom  -  Minneapolis
> ----------------------------
> JSF-EG, JSF-RI, EL, Facelets
>
>

Re: Abstracting JSF presentation from HTML?

[Jacob Hookom <ja...@hookom.net>]

I have written quite a bit on this topic in relation to components and 
CSS/XUL and the benefits of structual separation with components:

http://weblogs.java.net/blog/jhook/archive/2005/07/programmer_frie_1.html

Facelets ability to work with any markup (XUL included) and allowing 
custom compositions (UserTags) allows a great degree of flexability and 
re-use with JSF.

-- Jacob

Simon Kitching wrote:

> Korhonen, Kalle wrote:
>
>>> -----Original Message-----
>>> From: Adam Winer [mailto:awiner@gmail.com] Sent: Thursday, December 
>>> 15, 2005 11:23 AM
>>> Subject: Re: svn commit: r356552 - in Hope I'm not coming off as 
>>> insulting any of the committers here.  Especially 'cause I *totally* 
>>> agree that abstracting away from HTML is the only way to go.  I'm 
>>> just reacting with 
>>
>>
>> Adam, care to elaborate more on why you think abstracting away from HTML
>> is the only way to go? I.e. why not Tapestry-like approach (though I
>> guess you could see jwcid as abstracting away from HTML too)?
>>
>
> Well one obvious reason is to be able to render to different 
> presentation technologies. HTML is definitely *not* a perfect 
> presentation language that will last us into the next century :-).
>
> If the presentation is done in terms of widgets, eg by specifying a 
> "selectOneMenu" rather than a <SELECT> then this can be rendered as 
> HTML, or as Mozilla-XUL or any other presentation markup that may be 
> invented in the future.
>
> There are of course disadvantages to this too, particularly when JSF 
> is in as raw a state as currently. Often it is necessary to mix JSF 
> and HTML to get the necessary results, and the more abstract the JSF 
> presentation markup is the harder it is to do this. And using CSS for 
> presentation is simple when using a tapestry-like approach, but much 
> less so when using an "abstract" JSF view definition.
>
> Regards,
>
> Simon
>


-- 
Jacob Hookom  -  Minneapolis
----------------------------
JSF-EG, JSF-RI, EL, Facelets