AW: [Seaside] [ANN] Seaside Installer

Jason Johnson jbjohns at libsource.com
Thu Aug 10 14:13:20 UTC 2006


Yea, something like this is exactly what I was thinking of.  The session
subclasses could be overridden to allow arbitrary rendering classes to
be chosen based on a configurable set of rules (configurable from the
web site, to keep consistant with the rest of the design).  At that
point, you can do anything Cacoon, AxKit, etc. can do, but with no where
near the level of complexity those products have.

-----Ursprüngliche Nachricht-----
Von: seaside-bounces at lists.squeakfoundation.org
[mailto:seaside-bounces at lists.squeakfoundation.org] Im Auftrag von Bany,
Michel
Gesendet: Donnerstag, 10. August 2006 13:29
An: The Squeak Enterprise Aubergines Server - general discussion.
Betreff: RE: [Seaside] [ANN] Seaside Installer

Not sure if this helps here, but method #rendererClass does not
necessarily
need to return a constant. The class can be computed using data found
in the incoming request or even in the native request.

Computing the class of the output document based upon the request would
only need a small refactoring. In places where WAHtmlDocument is
referenced,
the actual document class would be supplied by the session where
session subclasses would be able to compute the actual document class.

Michel.



> -----Original Message-----
> From: seaside-bounces at lists.squeakfoundation.org 
> [mailto:seaside-bounces at lists.squeakfoundation.org] On Behalf 
> Of Philippe Marschall
> Sent: Thursday, August 10, 2006 1:00 PM
> To: The Squeak Enterprise Aubergines Server - general discussion.
> Subject: Re: [Seaside] [ANN] Seaside Installer
> 
> I'd do completely different components for XHTML and WML and 
> also different seaside applications. That's certainly the 
> easiest way. This way you can also use the normal 
> #renderContentOn: method, maybe rename the argument from html to wml.
> 
> I know of no plans to integrate that into seaside. Mainly 
> because noone has yet had any use for it. But I doubt that a 
> working implementation that doesn't break exisiting code 
> would be turned down.
> 
> It shouldn't be hard to produce a simple prototype. Do you 
> have any concrete plans for an application?
> 
> Philippe
> 
> 2006/8/10, Jason Johnson <jbjohns at libsource.com>:
> > Oh, sorry about that last send. *blush*.
> >
> > Yes, I'm sold on the idea that CSS is the media translation 
> for HTML 
> > (certainly a much better (X)HTML media translation then XSLT).  The 
> > concern was only over WML (or any other standard that might 
> talk to my 
> > browser in the near future).  I was curious what the 
> seaside solution 
> > to this would be.  The WML render class sounds great, so long as it 
> > gets called when a WML client requests a page.  Or a WMLRenderOn: 
> > method could work.  But is seaside planning on doing something for 
> > this or do I have to put some logic in my system to check 
> what kind of 
> > page got requested?
> >
> > Thanks very much for your reply,
> > Jason
> >
> > -----Ursprüngliche Nachricht-----
> > Von: seaside-bounces at lists.squeakfoundation.org
> > [mailto:seaside-bounces at lists.squeakfoundation.org] Im Auftrag von 
> > Philippe Marschall
> > Gesendet: Donnerstag, 10. August 2006 10:13
> > An: The Squeak Enterprise Aubergines Server - general discussion.
> > Betreff: Re: [Seaside] [ANN] Seaside Installer
> >
> > Hi
> >
> > 2006/8/9, Jason Johnson <jbjohns at libsource.com>:
> > > Wow, I just installed the installer and seaside looks even more 
> > > incredible then it did before.
> > >
> > > There was one question that was asked on the "HREF 
> considered harmful"
> > > site, and Avi answered most of the questions but not this 
> one which
> > was
> > > something I was conserned about myself.
> > >
> > > One user asked about generating XML instead of HTML
> >
> > Seaside produces (or should) XHTML which is XML.
> >
> > > directly and then
> > > doing XSLT conversions to get to the final output.  Avi 
> had a good 
> > > answer for this, except for the situation where the client is 
> > > actually
> > a
> > > phone or something like this.  How is the best way to handle the 
> > > situation when your client may be a normal web browser or 
> it may end
> > up
> > > being a phone or something?
> >
> > I'd say it depends whether you want to do WML or HTML.
> >
> > If you want to do HTML ideally a css for a different media type is 
> > enough.
> >
> > For WML a way would be to make a WmlRenderer (look at 
> WAHtmlCanvas and 
> > WARenderCanvas and adopt it) and a WAWmlDocument similar 
> > WAHtmlDocument. Then in your components override #rendererClass to 
> > return your new renderer class.
> >
> > > I had been writing, in my spare time, an apache module to convert 
> > > XML into some other form based on some rules (like cacoon, but 
> > > without the Java).  After seeing seaside, I have almost 
> completely 
> > > abandoned the idea.  The only thing that keeps it in the 
> back of my 
> > > mind is this question.
> > >
> > > Thanks,
> > > Jason
> > >
> >
> > _______________________________________________
> > Seaside mailing list
> > Seaside at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> >
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> 
_______________________________________________
Seaside mailing list
Seaside at lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside



More information about the Seaside mailing list