[Seaside] HTML method naming conventions

[Edward Stow]

On Fri, Apr 11, 2008 at 6:23 PM, Holger Kleinsorgen
<kleinsor at smallish.org> wrote:
>
> Edward Stow wrote:
>
> > On Fri, Apr 11, 2008 at 11:18 AM, Steve Aldred
> > <aldreds at velocitynet.com.au> wrote:
> >
> > > In the "SVG design questions" thread Philippe Marschall wrote:
> > >
> > >
> > > > Just a side note here. Wherever possible we tried to avoid the C-ish
> > > > names of html elements in Seaside and used full names instead. So
> > > > instead of #img we name #image. Here this would mean #rectangle
> > > > instead of #rect.
> > > >
> > > >
> > > >
> > >  Not trying to be difficult or anything but why?
> > >
> > >  Given to use Seaside you have to have a good understanding of HTML
> where is
> > > the advantage in translating tags to different message name? Renaming
> for
> > > the sake of being 'Smalltalkish" just makes entry for existing web
> > > developers that much more difficult. How many people have tried to send
> #tr
> > > and #td?
> > >
> >
> > + 1  I would prefer to use html tag names, td, tr, a.
> >
> > And seaside adds to the html language disconnect by using #url: for
> > src and href attributes.
> >
>
>
>  There's a SVG example that lets me agree with the "full names" policy:

>   ...
>
>  much easier to read.

In effect the seaside html rendering and the svg rendering examples
are a DSL but one that cannot be understood by itself.  I have to
agree that the code is neater .. but .. in both the html or svg
rendering my bet is that you 'debug' your documents by examining the
html / svg produced.  And that you work out what html/svg element /
attribute you need to add or change for the desired effect and then
write the corresponding smalltalk rendering code.  So in effect you
are working in both the html / svg and the domain specific languages.

But this issue is really small beer in relation to the advantages of Seaside.

-- 
Edward Stow