[Seaside] Seaside2: separation between content and presentation

[Alain Fischer]

Le Lundi 2 d=E9cembre 2002, =E0 12:28 , Avi Bryant a =E9crit :

>
> On Sun, 1 Dec 2002, Alain Fischer wrote:
>
>> Hi Seasiders,
>>
>> I have taken time to look at the new Seaside2. Congratulation, its a
>> nice piece of work.
>>
>> I like the way you have handled the Component history through the
>> ManagedObject class.
>> There is only one minor drawback I see: We could not use the "inst =
var
>> refs..." menu of the browser.
>
> That's interesting, I hadn't thought of that one.
> There's also an issue with inspecting/exploring components, although =
the
> web-based inspector works properly.  I imagine this could also be =
fixed
> with custom ObjectExplorerWrappers or some such, right?

I  need to see how are used these wrappers, but I think this could be=20
easy.

>> What is the future of Seaside2 (the Marquez part) ?
>> When will be Marquez released even if it is experimental ?
>> What is manner to handle this separation of you other web programmer =
?
>
> The way that I've been pushing in my own work is to have the =
programmer=20
> do
> all the HTML (using HtmlRenderer) and the designer work purely with =
CSS.
> However, that doesn't make sense in the scenario you're talking about
> where you're given HTML templates to begin with.  I think your three
> options below are probably the ones to consider for that case- let me=20=

> look
> at each of them:
>
>> 1) Using the templates of seaside0.94
>>      + very near to WebObjects, easy for simple templates
>>      - hard to do when the templates are hierachical.
>
> Your hierarchical point is a good one - if you mean what I think you=20=

> mean,
> it's that there's a tendency towards monolithic templates with no
> lightweight way to refactor them.  This is one reason I don't want to =
go
> back to that style of template.  The other main reason I dislike such
> templates is that you end up with the core of the component in a =
string
> literal or external text file - hard to refactor, things like "senders=20=

> of"
> don't work, you get no tool support (typo-checks at compile time, =
etc),
> and, worst of all, it's not smalltalk - so you're limited by whatever=20=

> the
> (necessarily ugly) template language provides.  WO-style bindings are=20=

> also
> a source of a lot of confusion for new users (unless you have the =
luxury
> of WOBuilder).
>
>> 2) Using XML/XSL style sheet (transformation could be on client =
browser
>> or on the server side)
>>       + w3c standard
>>       - not well supported on browser, authoring tools and web=20
>> designer.
>
> I haven't actually thought about this one, but it's an interesting=20
> idea -
> we could have an XMLRenderer that produced files suitable for=20
> translation.
> Think many web designers would go for that?  CSS seems like an easier=20=

> sell
> (and I'd rather not work with XSLT, personally, if I can avoid it).
>
>> 3) Converting html page in HTMLGenerator code
>>      A way to explore. Perhaps coupled with the refactoring browser =
to
>> cut one page in hierachical component.
>
> If all you want is a one time operation of "suck in HTML template,=20
> produce
> HTMLRenderer code, and go from there", this should be quite easy to =
do.
> The harder part is round tripping it - being able to reintegrate later
> changes to the template.  I don't have a good sense of how that could
> work, which is the main reason we haven't released anything like that.

Imagine the following fllow:
- parse the html file
- generate HTMLGenerator code
- use the RefactoringBrowser (or a modifieed one) to cut this page in=20
sub component
- include dynamic content, repetition and/or selection
- check the rendered result of this component with a pre generated or=20
archived content
- modifiy it to have the desired result.

Later, when you receive the same page but redesigned by the graphist,
you could flaten the component to see what was changed help with
some tools like Mac OS X FileMerge (a dual pane diff tool and merger).
Integrate these change to your component.

I don't know if cuting an html page is more easy with the=20
RefactoringBrowser
or the HTMLNodeExplorer I describe later.

>>      Some tool like object explorer modified to see only html =
structure
>> could bee good too.
>
> Can you elaborate on that?

In Seaside0.94, you could explore an html file in this way:
(IAHtmlParser parse: (FileStream fileNamed: 'MyPage.html')) explore
But the result is not easy to explore because the html tag represeted
by HTMLNode are always separated by the children collection.

I was thinking of a modifed ObjectExplorer (perhaps we can use=20
ObjectExplorerWrappers)
that could show a parsed html file in the following way (with an=20
expand-colapse triangle
in front of each lines):

html
     head
         title ....
     body
         h1 ....
         p ....
         hr
         form
             input
         table
             tr
                 td


> Also, if I may ask, just out of curiosity: what would it require for =
you
> to start doing some contracts with Seaside rather than WebObjects?  I
> imagine it's a fairly long list, but I'd love to know what it was.
>
> Cheers,
> Avi
>
> _______________________________________________
> Seaside mailing list
> Seaside@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/seaside
>