A practical problem for Traits (hopefully :)

Some time ago I stepped through the process of applying a new software  
layer to an existing package, without creating mutual dependency. The base  
package is Todd's excellent html+css parser+DOM

- http://www.squeaksource.com/htmlcssparser

I used the W3 spec for designing the new software layer

- http://www.w3.org/TR/xhtml-modularization/abstract_modules.html
- http://www.w3.org/TR/html4/sgml/dtd.html

The result is attached. It consists of Traits and the intended users of  
it. As yet no new method has been written; that's a bit too much for me at  
the moment. I still have not decided what to use, Morphic or Tweak. But if  
one of the layout experts would explain to me how to layout html+css in  
the Morphic or in the Tweak world then I'm sure this project can benefit  
 from your expertise.

As can be seen from the attached source code, W3's "modules" when  
implemented as Traits can be attached easily to Todd's fine classes,  
without any side effect, in a Monticello-friendly fashion. And if someone  
would decide to get rid of such "crap" then the Traits can as well be  
deimplemented without any side effect.

It's also easy to imagine that from here on more than *two* developers can  
work on the same project; for example one on the hmtl-lists, another on  
the html-forms, etc, without disturbing each other. And if one of them has  
a requirement, master package-owner has the power to rule. What else can a  
Squeaker want :)

The above can perhaps be used for debating Traits in Squeak. Fur sure the  
html+css engines belong to the most complicated pieces of software in this  
time on this planet. They do, in *parallel*, multiple http sessions,  
layout of parts, user interaction, security tasks, scripting, plug-in  
instantiation, resource constraints, etc, only for loading *one* single  
page from the web.

I would appreciate if the Traits discussion could be directed towards  
practical solutions for this practical problem. I hope that the html+css  
project can benefit from your expertise, experience and opinion.

/Klaus

I will have a look but here this is ***totally*** frantic.....arghhhh.

On 23 févr. 07, at 08:18, Klaus D. Witzel wrote:

Klaus D. Witzel wrote:
> As can be seen from the attached source code, W3's "modules" when
> implemented as Traits can be attached easily to Todd's fine classes,
> without any side effect, in a Monticello-friendly fashion. And if
> someone would decide to get rid of such "crap" then the Traits can as
> well be deimplemented without any side effect.

That is a very interesting (and to me novel) approach of applying
traits. I have two questions about this:
a) Since there is no code in the traits yet, it is hard to say how the
use of state would affect the ability to mix the various traits
depending on the ui framework chosen. Do you have any idea how to go
about state?
b) Is there any fundamental difference in doing what you did (using
traits) compared to what you would achieve with inheritance? Since
practically all subclasses are immediate children of the DOM node, one
could imagine to introduce a bit more hierarchy instead of mixing in
traits. How do you feel about that?

> I would appreciate if the Traits discussion could be directed towards
> practical solutions for this practical problem. I hope that the html+css
> project can benefit from your expertise, experience and opinion.

It's definitely nice to see something novel like this. Are you planning
on continued development? I would be very curious to follow this project
to see how it goes as more code needs to be handled.

Cheers,
   - Andreas

On Sat, 24 Feb 2007 07:13:15 +0100, Andreas Raab wrote:
I think that state must be hold in a subinstance of Model (with/without  
persistency). There can be many different models, but every traits layer  
(=library) naturally defines its own (=state). The model may reference the  
base material (html+css DOM in our case) or initially translate it for  
easing/speeding up accessors.

It will depend on the subproblem how/from where the model is referenced.  
For example an instance of MorphicLayoutManagerModel can be referenced  
with a dynamic variable, for the time it does its job (it resides only in  
the stack). Thereafter the components can have their layout accessible  
 from their respective view and LayoutManager can go away.

Does the above indicate how to mix various traits depending on the ui  
framework chosen?

> b) Is there any fundamental difference in doing what you did (using  
> traits) compared to what you would achieve with inheritance?

Yes. The html+css DOM base package must not neccessarily cooperate and the  
(library) boundaries are sharper (i.e. not just at the level of  
system/message category names).

> Since practically all subclasses are immediate children of the DOM node,  
> one could imagine to introduce a bit more hierarchy instead of mixing in  
> traits. How do you feel about that?

My perspective here is that of a team manager who wants his team to be  
very productive. Therefore I would not allow overrides between a base  
library and, say, a layout library. Instead, just a clear contract in form  
of methods required and methods provided (and *no* global references ;-)

As an example, if we take the part of your last question from above as  
"multiple ui frameworks, one of them to be choosen at run time" then the  
degree of isolation between the layers can raise but also can bring Rome  
to fall [pun intended].

The rest (for example, exploiting software composition) must be open to  
the creativity of the team members.

>> I would appreciate if the Traits discussion could be directed towards  
>> practical solutions for this practical problem. I hope that the  
>> html+css project can benefit from your expertise, experience and  
>> opinion.
>
> It's definitely nice to see something novel like this. Are you planning  
> on continued development?

Yes. But as already mentioned, I either become a layout expert for Morphic  
and Tweak, or else somebody can help me with that (as a tutor, mentor?).  
I'd be happily do all the necessary coding (when time permits).

> I would be very curious to follow this project to see how it goes as  
> more code needs to be handled.

Thank you for your attention Andreas.

/Klaus

> Cheers,
>    - Andreas
>
>