[Seaside] odds and ends

Wilkes Joiner wilkesjoiner at gmail.com
Wed Jun 29 22:10:53 CEST 2005


On 6/29/05, radoslav hodnicak <rh at 4096.sk> wrote:
> On Wed, 29 Jun 2005, Ramon Leon wrote:
> > I do, and I'd bet many others do to.  Web apps don't get the credit they
> > deserve because they're thought of too much as web pages and too little
> > as real applications.  Why shouldn't a web app be more like Photoshop
> > and let you doc stuff where you like?  Why shouldn't web forms be laid
> > out by the developer at run time with drag and drop while in design
> > mode?  It's trivial to use JavaScript and the DOM to generate the
> > necessary CSS to store a pages layout, why should CSS be written by hand
> > when it isn't necessary?
> >
> > I hate the name Ajax, but the techniques have been used for years and
> > still aren't used enough.  Seaside isn't for making web pages... other
> > frameworks do that much better, seaside is for web applications, and it
> > does that better than the rest, IMHO, and "full" Ajax support should be
> > built in as soon as possible.
> 
> Ok, first of all, I don't really have experience with developing "Ajax" (a
> stupid name indeed) kind of web applications, so don't take it as attack
> on this technology. Clearly, if/when it is available in Seaside nobody
> will force me to use it. I'm trying to get informed.

I always feel slightly embarrassed when I use the term Ajax.

> Issue #1 - Trust
> 
> I don't trust the browser. I won't ever use javascript to validate forms
> (not without a second check on the server, which makes the first check
> pointless), a http post is easy to fake. How many backdoors am I opening
> by using these new techniques, partially moving application logic from
> server to client?

Rather than coding up a bunch of Javascript and duplicating that logic
on the server, which you have to do for validations, you just make a
little post to the server that sends back XML, HTML, or even
Javascript back to the client to be handled.  Part of the idea is that
you are removing the need to duplicate logic on the client and on the
server to provide your user with a responsive interface.  If done
right, it is an appropriate separation of concerns.  All the app logic
resides on the server, and all the UI manipulation logic lives on the
client.  I think this is a good idea regardless of the technology.

> 
> Issue #2 - Development time
> 
> Debugging javascript in IE is a nightmare. It's somewhat better in
> mozillas. Generally, debugging outside of smalltalk takes longer than in
> smalltalk. I'm one of the few people who gets paid for seaside work. As
> cynical as it sounds, I'm not using smalltalk/seaside to provide my
> customers the best possible solution, I'm using it to provide my customers
> some set of features to make the app competitive, *with least possible
> effort on my side*. Will using these new techniques actually make my life
> as developer easier?

Yes and no.  Yes, it will be much easier to give your users a much
more interactive client if Ajax support is rolled into the web
framework.  No, you will be doing more work because you will be adding
more features to your web app, ;)

As far as debugging, Prototype handles a lot of the cross browser
issues and most of the javascript you will be writing will be
manipulating the DOM.  Developing with IE will still suck, but I think
the amount of debugging you do will be a lot less than you have
experienced with Javascript in the past.

The key to all of this is the integration with the framework.  I can't
think of a framework more suited to Ajax integration than Seaside.

BTW, I'm jealous you are getting paid to develop using Seaside.

- Wilkes


More information about the Seaside mailing list