[EMAIL PROTECTED] wrote:
>
> Raphael Luta wrote:
>
> > > I would think that a device negotiation layer as you could
> > call Cocoon would
> > > be extremely helpful working towards different devices - it
> > does already
> > > quite a lot of things in terms of user agent detection and the like.
> > >
> >
> > The browser detection of Cocoon definitely needs an
> > improvement. The main
> > issue being that it detects browsers and not *capabilities*.
>
> Some people on the Cocoon mailing list have start sending in patches doing
> some 'browscap' style UA detection. So I suppose this is heading into the
> right direction.
>
Definitely. I saw the posts on the mailing-list but not the patches...
> > Such a piece of code would be of tremendous use for many
> > Apache projects :
> > Turbine, Cocoon, Jetspeed, Jyve... and so should probably be
> > considered
> > part of the Avalon project.
> >
> > Of course, the difficult task in this is to keep track of all the
> > browsers capabilities...
>
> Problem is also that the interpretation of a certain capability sometimes
> differs from browser to browser. It's nice to know that both XYZ and ABC
> support JavaScript 3.98, but in our reality we would end up designing
> towards specific browsers, since they have a different interpretation for a
> certain JavaScript statement.
>
> I know this is kind of pragmatic, but reality kicks in when you design &
> build websites for a living.
>
Why not just downgrade the browser to the highest acceptable implementation of
a defined standard ?
If you define your sites with 3 L&F targets,
- HTML/CSS/DOM/javascript
- HTML3.2/javascript
- HTML/text/no table
you cover most of the available browser capabilities. If this means that
Netscape 4 users are given an HTML3.2 version because CSS and DOM support
were too crappy, so be it. Maybe this will give an incentive to correct
these issues.
My point is that you actually don't have to use all the features offered
by a browser, just stick to standard stuff. Used any <blink> tags lately ?
:)
> > For me: dynamic = user customizable. I'm waiting for Stefano proposal
> > to see what hooks would be available for jetspeed within the
> > sitemap, but
> > I fear SoC (separation of concerns, Stefano's mantra for
> > Cocoon 2) issues.
>
> The Action component gives you the possibility to specify some code (which
> has a required minimal interface) to invoke during a certain pipeline.
> Giacomo Pati told me you had full access to the Cocoon internals during the
> execution of that class but you could do all kinds of back-end stuff also
> within it (like accessing a DB, checking the session, etc...)
>
> That's what I understood from it, but IANAProgrammer :-|
>
Is that implemented yet ? I thought they were still working on designing
this, but it sure sounds like a cool idea.
> SoC is an issue of course, but offering a web publishing platform without
> some sound integration with a web application platform doesn't make much
> sense to me also, and I can't assume Stefano hasn't been thinking about that
> one also.
>
> After all, the sitemap could also be considered as being some kind of basic
> webapp (mapping the URI namespace into serverside content generation &
> filtering processes, where personalization sure needs to be an issue).
>
I'm not sure that the sitemap needs to be personalization aware, most of the
time personalization only occurs at the content level. Also the sitemap
currently knows how to select a resource based on personalization but
there's currently no provision for joining resources.
--
Rapha�l Luta - [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
