Design of WAComponent(s)
Locked
12
12
 
|
Hello!
Inspired by my own work needs on Seaside 2.8 on VisualWorks 7.6 and also by the recent discussion on MVC vs. Seaside I like to start a discussion about forming a generalization of components, giving them more inner structure and more uniformity. A more detailed model of WAComponent. Possibly there are projects running in the Squeak world that I do not know of and that make this discussion unnecessary. In that case I would be grateful for any pointers! To illustrate where I am coming from, let me pick one of the predefined components in the core: WATree. I picked this component because it is generally useful (a typical element of web applications) and because it supports my ideas nicely. The class comment says " WATree implements a tree menu, which supports nesting, collapsing and expanding. Prefixes items with "+/-" to indicate items that can be expanded/collapsed." If you look at the implementation then you see that it has several fundamentally different tasks: - provide a tree fascade over an arbitrary object - manage the selection in this tree model - manage the tree expansion/collapse model of the tree - create the XHTML presentation of the tree model - (indirectly) provide controller behavior by letting you place callbacks in the select: block Also the view part is rather inflexible in the XHTML generated: it builds an unordered list with constant css classes for the elements. I am an old school Smalltalker who values clear models and responsibilities. When I looked at this component, my first thought was "this is a bit much for one class" and the second one was "what is exactly the intended responsibility of components?". Add that you cannot have two trees on a page with different appearance (style) without some work, involving code duplication. If we split this class into independent concepts that can be recombined/varied in useful ways then we get: - a model of a tree - a model of the visual appearance (expand/collapse) of the tree model - a XHTML generator = a domain logic combining the above three with selection and interface to the application logic (callback) One can put the collapsed/expanded information into the domain logic object, which means a new WATree model will be constructed from a tree model and a matching XHTML generator. How is this useful? - stays object-oriented on the model side by encapsulating the tree model instead of exposing it in blocks - allows different renderings of such tree expansion state. Unordered lists of buttons, labels and associated children are fine but one option - allows more configuration control on the styles attached (ok this could be a simple useful addition to WATree in its current shape too) - when modeled right it allows to share XHTML rendering among components Interestingly, the shore components example has its own, rather differently implemented tree component with a dedicated model of the visual tree appearance and using tables instead of unordered lists. So by not providing the developer with a Seaside Component Framework, a lot of unnecessary development work and code duplication is taking place. I think the message to new developers should be "pick a component and configure it to your needs" instead of "look at the examples and program one for yourself". So what do you think? Is there a project/plans in this direction? Did I violate the principles of Seaside? Andreas -- Andreas Tönne Lead Consultant Cincom Systems GmbH & Co. oHG Tel.: +49 6196 9003 100 Mobile: +49 172 6159272 Fax: +49 6196 9003 270 Geschäftsführer/Managing Directors: Thomas M. Nies, Gerald L. Shawhan oHG mit Sitz/based in Schwalbach/Ts. (Amtsgericht Königstein/Ts. HRA 2653) Pers. haftender Gesellschafter/Partner liable to unlimited extent: Cincom Systems Verwaltungsgesellschaft mbH (Amtsgericht Königstein/ Ts. HRB 5069) _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
> responsibility of components?". Add that you cannot have two trees on a page
> with different appearance (style) without some work, involving code > duplication. Of course you can have different looking trees on a single page, you simply put them into a div-tag with a specific class/id. > If we split this class into independent concepts that can be > recombined/varied in useful ways then we get: > - a model of a tree > - a model of the visual appearance (expand/collapse) of the tree model > - a XHTML generator > = a domain logic combining the above three with selection and interface to > the application logic (callback) Maybe you want to the check the history of WATree in the mailing list? Why it was put into Seaside-Core and why it will be gone in Seaside 2.9. The goal of WATree is to give a component for quick prototyping and as such it is probably not useful for your specific needs. > development work and code duplication is taking place. I think the message > to new developers should be "pick a component and configure it to your > needs" instead of "look at the examples and program one for yourself". I guess most people start with one of the ready-made components and use it until they hit the limits. And only then they start to subclass or write their own widget. Of course it would be nice if WATree was more configurable, but I doubt a newbie would prefer it over the simplicity of WATree. Having to provide several models for a working tree, reminds me of my worst nightmares when looking at the code of students that use Swing JTable for the first time. It is so simple and quick to create my own widget that does exactly what I need, why should I bother with a huge library that could do everything after hours of configuration? > So what do you think? Is there a project/plans in this direction? Did I > violate the principles of Seaside? There are several projects working on widget libraries. You mentioned ShoreComponents. Scriptaculous-Components is another one, focusing on widgets with AJAX interaction. Both approaches don't provide much more than a few configuration blocks. It certainly does not violate the principles of Seaside. It might be worth to investigate how well this scales? Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Lukas Renggli wrote:
> Maybe you want to the check the history of WATree in the mailing list? > Why it was put into Seaside-Core and why it will be gone in Seaside > 2.9. > Does that mean there won't be a tree widget at all? We've found trees very useful as a means of browsing complex data. They can be used like compact vertical tabs, people readily understand drilling down (node expansion) through detail. On selection a linked pane can completely change its format to suit the detail of the tree node selected. cheers Steve _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
> Does that mean there won't be a tree widget at all?
Sure, it will be in some extra package, but not in the core anymore. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Lukas Renggli
Lukas,
please do not overrate my choice of WATree. My ideas were more general. I did not know that WATree has such special status or else I would have picked another example. You said > It is so simple and quick to create my own widget that does exactly > what I need, why should I bother with a huge library that could do > everything after hours of configuration? and this is a point where I disagree. Surely I follow your aversion against an Überframework like Swing. But I have seen too many copy&paste applications to know that the average developer out there needs and likes some guidance through designed inner structure of frameworks. Right now things are small and the number of components is manageable. With a growing number of components and component features I fear that we might see a similar development as the wrapper framework of VisualWorks. It used to be based on a simple, clear and powerful model. Then step by step it got overloaded by features and variation. Today its implementation is "baked together" with a lot of copy&paste. Your suggestion to name multiple trees (or other components for that matter) through enclosing DIV is exactly one of those principles I am looking at. For the purpose of XHTML generation a component might need a name for its styles. The programmers choice is to *know* that one names components externally by enclosing them in a DIV and using path names to specify dedicated styles. The designers choice is to place this knowledge into the component and make it one of the options a user of the component might take. Another example of this implementation vs. design choice is the composition of components. Right now a component uses a composite pattern by convention. I would prefer the composite pattern to be pre-implemented. I am sure this has been discussed excessively already :-) Did you refer to this mailing list or to seaside-dev for the 2.9 features discussions? If you like to see how such frameworks scale, I will try this out. See it anytime next month on www.smalltalk80.de. Andreas Am 05.03.2008 11:58 Uhr schrieb "Lukas Renggli" unter <[hidden email]>: >> responsibility of components?". Add that you cannot have two trees on a page >> with different appearance (style) without some work, involving code >> duplication. > > Of course you can have different looking trees on a single page, you > simply put them into a div-tag with a specific class/id. > >> If we split this class into independent concepts that can be >> recombined/varied in useful ways then we get: >> - a model of a tree >> - a model of the visual appearance (expand/collapse) of the tree model >> - a XHTML generator >> = a domain logic combining the above three with selection and interface to >> the application logic (callback) > > Maybe you want to the check the history of WATree in the mailing list? > Why it was put into Seaside-Core and why it will be gone in Seaside > 2.9. > > The goal of WATree is to give a component for quick prototyping and as > such it is probably not useful for your specific needs. > >> development work and code duplication is taking place. I think the message >> to new developers should be "pick a component and configure it to your >> needs" instead of "look at the examples and program one for yourself". > > I guess most people start with one of the ready-made components and > use it until they hit the limits. And only then they start to subclass > or write their own widget. > > Of course it would be nice if WATree was more configurable, but I > doubt a newbie would prefer it over the simplicity of WATree. Having > to provide several models for a working tree, reminds me of my worst > nightmares when looking at the code of students that use Swing JTable > for the first time. > > It is so simple and quick to create my own widget that does exactly > what I need, why should I bother with a huge library that could do > everything after hours of configuration? > >> So what do you think? Is there a project/plans in this direction? Did I >> violate the principles of Seaside? > > There are several projects working on widget libraries. You mentioned > ShoreComponents. Scriptaculous-Components is another one, focusing on > widgets with AJAX interaction. Both approaches don't provide much more > than a few configuration blocks. > > It certainly does not violate the principles of Seaside. It might be > worth to investigate how well this scales? > > Cheers, > Lukas -- Andreas Tönne Lead Consultant Cincom Systems GmbH & Co. oHG Tel.: +49 6196 9003 100 Mobile: +49 172 6159272 Fax: +49 6196 9003 270 Geschäftsführer/Managing Directors: Thomas M. Nies, Gerald L. Shawhan oHG mit Sitz/based in Schwalbach/Ts. (Amtsgericht Königstein/Ts. HRA 2653) Pers. haftender Gesellschafter/Partner liable to unlimited extent: Cincom Systems Verwaltungsgesellschaft mbH (Amtsgericht Königstein/ Ts. HRB 5069) _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
> please do not overrate my choice of WATree. My ideas were more general. I
> did not know that WATree has such special status or else I would have picked > another example. Sure, there are many similar examples. > > It is so simple and quick to create my own widget that does exactly > > what I need, why should I bother with a huge library that could do > > everything after hours of configuration? > > and this is a point where I disagree. Surely I follow your aversion against > an Überframework like Swing. But I have seen too many copy&paste > applications to know that the average developer out there needs and likes > some guidance through designed inner structure of frameworks. I should have added: "... and it is hard to create a widget that fits all needs." I guess WATableReport (or WATreeReport) is already a bit closer to your imagination (they both have a model for their columns)? > Right now things are small and the number of components is manageable. With > a growing number of components and component features I fear that we might > see a similar development as the wrapper framework of VisualWorks. It used > to be based on a simple, clear and powerful model. Then step by step it got > overloaded by features and variation. Today its implementation is "baked > together" with a lot of copy&paste. Seaside 2.8 is slightly smaller than Seaside 2.7, without dropping functionality. Seaside 2.9 will be much smaller than Seaside 2.8, by separately packaging external functionality. > Another example of this implementation vs. design choice is the composition > of components. Right now a component uses a composite pattern by convention. > I would prefer the composite pattern to be pre-implemented. I am sure this > has been discussed excessively already :-) There used to be WAContainer and WAFrameComponent. WAContainer was dropped a long time ago because its functionality was integrated into WAComponent. WAFrameComponent was dropped in Seaside 2.7, because there were no users. > Did you refer to this mailing list or to seaside-dev for the 2.9 features > discussions? To this mailing-list. seaside-dev is not that old ;-) > If you like to see how such frameworks scale, I will try this out. I am interested too. Keep us updated. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Design of WAComponent(s)
|
|
In reply to this post by Andreas Tönne
Hi Andreas,
I think is not MVC vs. Seaside. I think Seaside is a platform which provides solutions to a certain point but also allows you to take that point as a start of something bigger. I'm taking advantage of Seaside to make one by one a more complex (an powerful) kind of components which makes the developer to feel like programing widgets in a desktop application. In fact pretty much Dolphin Smalltalk style which is MVP, a variation of MVC. For me is no discussion to make because it's working so well. I even make the javascript part on this components to be inheritable, beacouse it's supported by the smalltalk hierarchy, and dinamically updateable (after an updater you can make a DOM element to behave differently). And is so easy that the tooltip I saw being discussed will be easier and more powerful to make from seaside itself than to wrap that ProtoTip. cheers, Sebastian Sastre > -----Mensaje original----- > De: [hidden email] > [mailto:[hidden email]] En nombre > de Andreas T ö nne > Enviado el: Miércoles, 05 de Marzo de 2008 07:30 > Para: [hidden email] > Asunto: [Seaside] Design of WAComponent(s) > > Hello! > > Inspired by my own work needs on Seaside 2.8 on VisualWorks > 7.6 and also by > the recent discussion on MVC vs. Seaside I like to start a > discussion about > forming a generalization of components, giving them more > inner structure and > more uniformity. A more detailed model of WAComponent. > Possibly there are > projects running in the Squeak world that I do not know of > and that make > this discussion unnecessary. In that case I would be grateful for any > pointers! > > To illustrate where I am coming from, let me pick one of the > predefined > components in the core: WATree. I picked this component because it is > generally useful (a typical element of web applications) and > because it > supports my ideas nicely. > > The class comment says " WATree implements a tree menu, which supports > nesting, collapsing and expanding. Prefixes items with "+/-" > to indicate > items that can be expanded/collapsed." > > If you look at the implementation then you see that it has several > fundamentally different tasks: > > - provide a tree fascade over an arbitrary object > - manage the selection in this tree model > - manage the tree expansion/collapse model of the tree > - create the XHTML presentation of the tree model > - (indirectly) provide controller behavior by letting you > place callbacks in > the select: block > > Also the view part is rather inflexible in the XHTML > generated: it builds an > unordered list with constant css classes for the elements. > > I am an old school Smalltalker who values clear models and > responsibilities. > When I looked at this component, my first thought was "this > is a bit much > for one class" and the second one was "what is exactly the intended > responsibility of components?". Add that you cannot have two > trees on a page > with different appearance (style) without some work, involving code > duplication. > > If we split this class into independent concepts that can be > recombined/varied in useful ways then we get: > - a model of a tree > - a model of the visual appearance (expand/collapse) of the tree model > - a XHTML generator > = a domain logic combining the above three with selection and > interface to > the application logic (callback) > > One can put the collapsed/expanded information into the > domain logic object, > which means a new WATree model will be constructed from a > tree model and a > matching XHTML generator. How is this useful? > > - stays object-oriented on the model side by encapsulating > the tree model > instead of exposing it in blocks > - allows different renderings of such tree expansion state. > Unordered lists > of buttons, labels and associated children are fine but one option > - allows more configuration control on the styles attached > (ok this could be > a simple useful addition to WATree in its current shape too) > - when modeled right it allows to share XHTML rendering among > components > > Interestingly, the shore components example has its own, > rather differently > implemented tree component with a dedicated model of the visual tree > appearance and using tables instead of unordered lists. So by > not providing > the developer with a Seaside Component Framework, a lot of unnecessary > development work and code duplication is taking place. I > think the message > to new developers should be "pick a component and configure it to your > needs" instead of "look at the examples and program one for yourself". > > So what do you think? Is there a project/plans in this > direction? Did I > violate the principles of Seaside? > > Andreas > > -- > Andreas Tönne > Lead Consultant > Cincom Systems GmbH & Co. oHG > Tel.: +49 6196 9003 100 > Mobile: +49 172 6159272 > Fax: +49 6196 9003 270 > > Geschäftsführer/Managing Directors: Thomas M. Nies, Gerald L. Shawhan > oHG mit Sitz/based in Schwalbach/Ts. (Amtsgericht Königstein/Ts. HRA > 2653) > Pers. haftender Gesellschafter/Partner liable to unlimited extent: > Cincom Systems Verwaltungsgesellschaft mbH (Amtsgericht Königstein/ > Ts. HRB 5069) > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Design of WAComponent(s)
|
|
In reply to this post by Andreas Tönne
2008/3/5, Andreas Tönne <[hidden email]>:
> .... I think the main point to understand here is that the components that come with Seaside are not a component library or even a component framework. They are simple stand alone components. They are not made with reusabilty, configurabitlity or customyzability in mind. They are focused on KISS and "getting the job done" and mostly for use Seaside itself. They will get you started fast but at one point sooner rather than later you will hit their limits. That's ok, they're not supposed to be the "be all, end all". The points you made IMHO apply only if you want to build a component library or even component framework. That should be an addon protect and has no place in Seaside-Core. Honestly I have my doubts if such a such thing could ever work given the very special needs of users concerning not only functionality but also mark up. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Design of WAComponent(s)
|
|
+1, for example there's no way I could see a standard "login" component work for us, let alone anything else that I can think of. Components is something you build as you make up your own application, its not something you take off the shelf and plug in.
-Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. > -----Original Message----- > From: [hidden email] [mailto:seaside- > [hidden email]] On Behalf Of Philippe Marschall > Sent: Wednesday, March 05, 2008 12:25 PM > To: Seaside - general discussion > Subject: Re: [Seaside] Design of WAComponent(s) > > 2008/3/5, Andreas Tönne <[hidden email]>: > > .... > > I think the main point to understand here is that the components that > come with Seaside are not a component library or even a component > framework. They are simple stand alone components. They are not made > with reusabilty, configurabitlity or customyzability in mind. They are > focused on KISS and "getting the job done" and mostly for use Seaside > itself. They will get you started fast but at one point sooner rather > than later you will hit their limits. That's ok, they're not supposed > to be the "be all, end all". > > The points you made IMHO apply only if you want to build a component > library or even component framework. That should be an addon protect > and has no place in Seaside-Core. Honestly I have my doubts if such a > such thing could ever work given the very special needs of users > concerning not only functionality but also mark up. > > Cheers > Philippe seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
> Subject: RE: [Seaside] Design of WAComponent(s)
> > +1, for example there's no way I could see a standard "login" > component work for us, let alone anything else that I can > think of. Components is something you build as you make up > your own application, its not something you take off the > shelf and plug in. > > -Boris +2, the components that are included in Seaside are more useful as examples rather than reusable widgets, and though I haven't kept up with 2.9, hopefully they're being ejected into another package because they don't belong in Core, they belong in external widget libraries. All widget libraries have limitations, there's no such thing as a generic widget that works for everyone. In web apps, in many cases, you'll end up rolling your own, or living with the limitations of some other library like Yahoo widgets or Mootools or something. The only reusable widgets you'll ever be happy with, are the ones you roll yourself and share between your own projects. Ramon Leon http://onsmalltalk.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Design of WAComponent(s)
|
|
In reply to this post by Philippe Marschall
> -----Mensaje original-----
> De: [hidden email] > [mailto:[hidden email]] En nombre > de Philippe Marschall > Enviado el: Miércoles, 05 de Marzo de 2008 17:25 > Para: Seaside - general discussion > Asunto: Re: [Seaside] Design of WAComponent(s) > > 2008/3/5, Andreas Tönne <[hidden email]>: > > .... > > I think the main point to understand here is that the components that > come with Seaside are not a component library or even a component > framework. They are simple stand alone components. They are not made > with reusabilty, configurabitlity or customyzability in mind. They are > focused on KISS and "getting the job done" and mostly for use Seaside > itself. They will get you started fast but at one point sooner rather > than later you will hit their limits. That's ok, they're not supposed > to be the "be all, end all". > > The points you made IMHO apply only if you want to build a component > library or even component framework. That should be an addon protect > and has no place in Seaside-Core. Honestly I have my doubts if such a > such thing could ever work given the very special needs of users > concerning not only functionality but also mark up. > > Cheers > Philippe > Quoting you: "...They are not made with reusabilty, configurabitlity or customyzability in mind..." Quoting Seaside site: "About Seaside provides a layered set of abstractions over HTTP and HTML that let you build highly interactive web applications quickly, reusably and maintainably. ..." Note that *reusably* is the second *bold* word after quickly. And also (from same source): "...Embedded components. Stop thinking a whole page at a time; Seaside lets you build your UI as a tree of individual, stateful component objects, each encapsulating a small part of a page. Often, these can be used over and over again, within and between applications - nearly every application, for example, needs a way to present a batched list of search results, or a table with sortable columns, and Seaside includes components for these out the box..." So? Sebastian _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Design of WAComponent(s)
|
|
Hi sebastian
I still see the point of andreas. I would love to have a usable report widget in which I can plug other components. I already sent that a while back but once I show Seaside to a guy at microsoft. He was impressed then after 3 min he asked me how many widgets are ready to use. And he was right. There are no incompatibilities between seaside as it is now and a cool widgets set. Having a cool widgets set with basic but fully working widgets would be a big plus: we could prototype even faster our applications. I do not have the skills and time of lukas to create widgets from scratch. But I imagine that I should be able to reuse them. Stef On Mar 6, 2008, at 5:10 PM, Sebastian Sastre wrote: >> -----Mensaje original----- >> De: [hidden email] >> [mailto:[hidden email]] En nombre >> de Philippe Marschall >> Enviado el: Miércoles, 05 de Marzo de 2008 17:25 >> Para: Seaside - general discussion >> Asunto: Re: [Seaside] Design of WAComponent(s) >> >> 2008/3/5, Andreas Tönne <[hidden email]>: >>> .... >> >> I think the main point to understand here is that the components that >> come with Seaside are not a component library or even a component >> framework. They are simple stand alone components. They are not made >> with reusabilty, configurabitlity or customyzability in mind. They >> are >> focused on KISS and "getting the job done" and mostly for use Seaside >> itself. They will get you started fast but at one point sooner rather >> than later you will hit their limits. That's ok, they're not supposed >> to be the "be all, end all". >> >> The points you made IMHO apply only if you want to build a component >> library or even component framework. That should be an addon protect >> and has no place in Seaside-Core. Honestly I have my doubts if such a >> such thing could ever work given the very special needs of users >> concerning not only functionality but also mark up. >> >> Cheers >> Philippe >> > > Quoting you: > "...They are not made with reusabilty, configurabitlity or > customyzability in mind..." > > Quoting Seaside site: > "About > Seaside provides a layered set of abstractions over HTTP and HTML > that let you build highly interactive web applications quickly, > reusably and maintainably. > ..." > > Note that *reusably* is the second *bold* word after quickly. > > And also (from same source): > "...Embedded components. Stop thinking a whole page at a time; > Seaside lets you build your UI as a tree of individual, stateful > component objects, each encapsulating a small part of a page. Often, > these can be used over and over again, within and between > applications - nearly every application, for example, needs a way to > present a batched list of search results, or a table with sortable > columns, and Seaside includes components for these out the box..." > > So? > > Sebastian > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Stephane,
thank you for getting my point. ;-) All, I found the various objectives for Seaside hiding behind the answers very interesting. No offense please but some answers show a lack of appreciation for the users of Seaside. If you want to grow the users base of Seaside, you need to answer the question of Microsoft. If you dont, it will remain a great tool from specialists for specialists. And fade in oblivion eventually. Let me get some points about my objectives straight (because some jumped to conclusions). 1. I do not look at a "one-framework-fits-it-all" approach. I know the limitations of a pluggable design for components. It is extremely hard! (designing Smalltalk applications for 21 years should qualify me to say that) Particularly the mixing of structure, presentation and interactivity in one XHTML structure limits the configuration choices for a general framework alot. (but I see a value in getting there half way) 2. I agree that the core should be small and needs some cleanup (and commenting please). Having said that, please think about this statement of Stephane for a minute: > I do not have the skills and time of lukas to create widgets from scratch. > But I imagine that I should be able to reuse them. Chapeau! That *IS* the main point. Those non-specialist that might be attracted to Seaside and Smalltalk are very likely not fluent in the details of XHTML, Java-script and AJAX. Asking them to create new components from the given examples will end in bad copy&paste programming. One interesting point is the size or specialization of predefined components. A login component is indeed not very interesting for a predefined component. Individual widgets that need to be pieced together from primitive HTML and AJAX elements are much more promising. These *expected* elements for UI design are pretty much standard and hence open for a standard implementation. I shoot for 80:20. I like to catch 80% of the standard widgets and components and let 20% be custom implementations. Andreas Am 06.03.2008 17:21 Uhr schrieb "stephane ducasse" unter <[hidden email]>: > Hi sebastian > > I still see the point of andreas. > I would love to have a usable report widget in which I can plug other > components. > I already sent that a while back but once I show Seaside to a guy at > microsoft. > He was impressed then after 3 min he asked me how many widgets are > ready to use. > And he was right. > > There are no incompatibilities between seaside as it is now and a cool > widgets set. > Having a cool widgets set with basic but fully working widgets would > be a big plus: we could > prototype even faster our applications. I do not have the skills and > time of lukas > to create widgets from scratch. But I imagine that I should be able to > reuse them. > > Stef > > > On Mar 6, 2008, at 5:10 PM, Sebastian Sastre wrote: > >>> -----Mensaje original----- >>> De: [hidden email] >>> [mailto:[hidden email]] En nombre >>> de Philippe Marschall >>> Enviado el: Miércoles, 05 de Marzo de 2008 17:25 >>> Para: Seaside - general discussion >>> Asunto: Re: [Seaside] Design of WAComponent(s) >>> >>> 2008/3/5, Andreas Tönne <[hidden email]>: >>>> .... >>> >>> I think the main point to understand here is that the components that >>> come with Seaside are not a component library or even a component >>> framework. They are simple stand alone components. They are not made >>> with reusabilty, configurabitlity or customyzability in mind. They >>> are >>> focused on KISS and "getting the job done" and mostly for use Seaside >>> itself. They will get you started fast but at one point sooner rather >>> than later you will hit their limits. That's ok, they're not supposed >>> to be the "be all, end all". >>> >>> The points you made IMHO apply only if you want to build a component >>> library or even component framework. That should be an addon protect >>> and has no place in Seaside-Core. Honestly I have my doubts if such a >>> such thing could ever work given the very special needs of users >>> concerning not only functionality but also mark up. >>> >>> Cheers >>> Philippe >>> >> >> Quoting you: >> "...They are not made with reusabilty, configurabitlity or >> customyzability in mind..." >> >> Quoting Seaside site: >> "About >> Seaside provides a layered set of abstractions over HTTP and HTML >> that let you build highly interactive web applications quickly, >> reusably and maintainably. >> ..." >> >> Note that *reusably* is the second *bold* word after quickly. >> >> And also (from same source): >> "...Embedded components. Stop thinking a whole page at a time; >> Seaside lets you build your UI as a tree of individual, stateful >> component objects, each encapsulating a small part of a page. Often, >> these can be used over and over again, within and between >> applications - nearly every application, for example, needs a way to >> present a batched list of search results, or a table with sortable >> columns, and Seaside includes components for these out the box..." >> >> So? >> >> Sebastian >> >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside -- Andreas Tönne Lead Consultant Cincom Systems GmbH & Co. oHG Tel.: +49 6196 9003 100 Mobile: +49 172 6159272 Fax: +49 6196 9003 270 Geschäftsführer/Managing Directors: Thomas M. Nies, Gerald L. Shawhan oHG mit Sitz/based in Schwalbach/Ts. (Amtsgericht Königstein/Ts. HRA 2653) Pers. haftender Gesellschafter/Partner liable to unlimited extent: Cincom Systems Verwaltungsgesellschaft mbH (Amtsgericht Königstein/ Ts. HRB 5069) _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Design of WAComponent(s)
|
|
In reply to this post by Andreas Tönne
Ah, but widgets are different from components. Widget may be a date picker and component may be a login prompt. I'm all for having widgets so long as their markup is well designed not to interfere outright with peoples work, but I can't see components being general enough to be useful, those you build up yourself as pieces of your application. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Andreas Tönne
> No offense please but some answers show a lack of
> appreciation for the users of Seaside. If you want to grow > the users base of Seaside, you need to answer the question of > Microsoft. If you dont, it will remain a great tool from > specialists for specialists. And fade in oblivion eventually. Why? Emacs and Vi do pretty well as editors without catering to newbies, why the assumption that building tools for experienced programmers is somehow fatal? Seaside is a framework, not a component library. > > I do not have the skills and time of lukas to create > widgets from scratch. > > But I imagine that I should be able to reuse them. > > Chapeau! That *IS* the main point. Those non-specialist that > might be attracted to Seaside and Smalltalk are very likely > not fluent in the details of XHTML, Java-script and AJAX. > Asking them to create new components from the given examples > will end in bad copy&paste programming. How does that have anything to do with whether the core should or shouldn't include generic components? No one is saying reusable components are bad, look at ShoreComponents, that is how generic components should be done, as separate packages that don't bloat the core framework. It'd be great to have a wide variety of component options, no one disputes that, they just don't belong in the core framework. BTW, anyone not fluent in the details of XHTML, Javascript and AJAX isn't going to make it very far in *any* web framework. If you want to develop web applications, these things are pretty much required learning. Seaside may let you write XHTML, Javascript, and Ajaxy stuff in Smalltalk syntax, but you still have to understand them to make effective use of those abstractions. There's no getting around that. Ramon Leon http://onsmalltalk.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Design of WAComponent(s)
|
|
In reply to this post by Andreas Tönne
Go do it!
Once you get some component I can try to rewrite my dead simple but boring to code Comix collection app (search, sorted result, report table with comix component view inside). Stef On Mar 6, 2008, at 5:52 PM, Andreas Tönne wrote: > Stephane, > > thank you for getting my point. ;-) > > All, > > I found the various objectives for Seaside hiding behind the answers > very > interesting. > > No offense please but some answers show a lack of appreciation for > the users > of Seaside. If you want to grow the users base of Seaside, you need to > answer the question of Microsoft. If you dont, it will remain a > great tool > from specialists for specialists. And fade in oblivion eventually. > > Let me get some points about my objectives straight (because some > jumped to > conclusions). > > 1. I do not look at a "one-framework-fits-it-all" approach. I know the > limitations of a pluggable design for components. It is extremely > hard! > (designing Smalltalk applications for 21 years should qualify me to > say > that) Particularly the mixing of structure, presentation and > interactivity > in one XHTML structure limits the configuration choices for a general > framework alot. (but I see a value in getting there half way) > 2. I agree that the core should be small and needs some cleanup (and > commenting please). > > Having said that, please think about this statement of Stephane for a > minute: > >> I do not have the skills and time of lukas to create widgets from >> scratch. >> But I imagine that I should be able to reuse them. > > Chapeau! That *IS* the main point. Those non-specialist that might be > attracted to Seaside and Smalltalk are very likely not fluent in the > details > of XHTML, Java-script and AJAX. Asking them to create new components > from > the given examples will end in bad copy&paste programming. > > One interesting point is the size or specialization of predefined > components. A login component is indeed not very interesting for a > predefined component. Individual widgets that need to be pieced > together > from primitive HTML and AJAX elements are much more promising. These > *expected* elements for UI design are pretty much standard and hence > open > for a standard implementation. I shoot for 80:20. I like to catch > 80% of the > standard widgets and components and let 20% be custom implementations. > > Andreas > > > Am 06.03.2008 17:21 Uhr schrieb "stephane ducasse" unter > <[hidden email]>: > >> Hi sebastian >> >> I still see the point of andreas. >> I would love to have a usable report widget in which I can plug other >> components. >> I already sent that a while back but once I show Seaside to a guy at >> microsoft. >> He was impressed then after 3 min he asked me how many widgets are >> ready to use. >> And he was right. >> >> There are no incompatibilities between seaside as it is now and a >> cool >> widgets set. >> Having a cool widgets set with basic but fully working widgets would >> be a big plus: we could >> prototype even faster our applications. I do not have the skills and >> time of lukas >> to create widgets from scratch. But I imagine that I should be able >> to >> reuse them. >> >> Stef >> >> >> On Mar 6, 2008, at 5:10 PM, Sebastian Sastre wrote: >> >>>> -----Mensaje original----- >>>> De: [hidden email] >>>> [mailto:[hidden email]] En nombre >>>> de Philippe Marschall >>>> Enviado el: Miércoles, 05 de Marzo de 2008 17:25 >>>> Para: Seaside - general discussion >>>> Asunto: Re: [Seaside] Design of WAComponent(s) >>>> >>>> 2008/3/5, Andreas Tönne <[hidden email]>: >>>>> .... >>>> >>>> I think the main point to understand here is that the components >>>> that >>>> come with Seaside are not a component library or even a component >>>> framework. They are simple stand alone components. They are not >>>> made >>>> with reusabilty, configurabitlity or customyzability in mind. They >>>> are >>>> focused on KISS and "getting the job done" and mostly for use >>>> Seaside >>>> itself. They will get you started fast but at one point sooner >>>> rather >>>> than later you will hit their limits. That's ok, they're not >>>> supposed >>>> to be the "be all, end all". >>>> >>>> The points you made IMHO apply only if you want to build a >>>> component >>>> library or even component framework. That should be an addon >>>> protect >>>> and has no place in Seaside-Core. Honestly I have my doubts if >>>> such a >>>> such thing could ever work given the very special needs of users >>>> concerning not only functionality but also mark up. >>>> >>>> Cheers >>>> Philippe >>>> >>> >>> Quoting you: >>> "...They are not made with reusabilty, configurabitlity or >>> customyzability in mind..." >>> >>> Quoting Seaside site: >>> "About >>> Seaside provides a layered set of abstractions over HTTP and HTML >>> that let you build highly interactive web applications quickly, >>> reusably and maintainably. >>> ..." >>> >>> Note that *reusably* is the second *bold* word after quickly. >>> >>> And also (from same source): >>> "...Embedded components. Stop thinking a whole page at a time; >>> Seaside lets you build your UI as a tree of individual, stateful >>> component objects, each encapsulating a small part of a page. Often, >>> these can be used over and over again, within and between >>> applications - nearly every application, for example, needs a way to >>> present a batched list of search results, or a table with sortable >>> columns, and Seaside includes components for these out the box..." >>> >>> So? >>> >>> Sebastian >>> >>> _______________________________________________ >>> seaside mailing list >>> [hidden email] >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>> >> >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > -- > Andreas Tönne > Lead Consultant > Cincom Systems GmbH & Co. oHG > Tel.: +49 6196 9003 100 > Mobile: +49 172 6159272 > Fax: +49 6196 9003 270 > > Geschäftsführer/Managing Directors: Thomas M. Nies, Gerald L. Shawhan > oHG mit Sitz/based in Schwalbach/Ts. (Amtsgericht Königstein/Ts. HRA > 2653) > Pers. haftender Gesellschafter/Partner liable to unlimited extent: > Cincom Systems Verwaltungsgesellschaft mbH (Amtsgericht Königstein/ > Ts. HRB 5069) > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Design of WAComponent(s)
|
|
In reply to this post by Andreas Tönne
> -----Mensaje original----- > De: [hidden email] > [mailto:[hidden email]] En nombre > de Andreas T ö nne > Enviado el: Jueves, 06 de Marzo de 2008 13:53 > Para: Seaside - general discussion > Asunto: Re: [Seaside] Design of WAComponent(s) > > Stephane, > > thank you for getting my point. ;-) > > All, > > I found the various objectives for Seaside hiding behind the > answers very > interesting. > > No offense please but some answers show a lack of > appreciation for the users > of Seaside. If you want to grow the users base of Seaside, you need to > answer the question of Microsoft. If you dont, it will remain > a great tool > from specialists for specialists. And fade in oblivion eventually. > > Let me get some points about my objectives straight (because > some jumped to > conclusions). > > 1. I do not look at a "one-framework-fits-it-all" approach. I know the > limitations of a pluggable design for components. It is > extremely hard! > (designing Smalltalk applications for 21 years should qualify > me to say > that) Particularly the mixing of structure, presentation and > interactivity > in one XHTML structure limits the configuration choices for a general > framework alot. (but I see a value in getting there half way) > 2. I agree that the core should be small and needs some cleanup (and > commenting please). > > Having said that, please think about this statement of Stephane for a > minute: > > > I do not have the skills and time of lukas to create > widgets from scratch. > > But I imagine that I should be able to reuse them. > > Chapeau! That *IS* the main point. Those non-specialist that might be > attracted to Seaside and Smalltalk are very likely not fluent > in the details > of XHTML, Java-script and AJAX. Asking them to create new > components from > the given examples will end in bad copy&paste programming. > > One interesting point is the size or specialization of predefined > components. A login component is indeed not very interesting for a > predefined component. Individual widgets that need to be > pieced together > from primitive HTML and AJAX elements are much more promising. These > *expected* elements for UI design are pretty much standard > and hence open > for a standard implementation. I shoot for 80:20. I like to > catch 80% of the > standard widgets and components and let 20% be custom implementations. > > Andreas > I've taken some trade offs and what you've described in your last paragraph is exactly what I've done in my hierarchy. All that thanks to the amazing Seaside platform. Let me count to give an idea.. 7 inputs (text, password, boolean, date, etc) including an autocompleter from my own (all the js but prototype cames from objects from the image and is not plain text). 4 values (non inputs) 14 other controls (tabs, anchor, menu, menu from button, etc) 4 layouts (flow horizontal, flow vertical and border covers 99.9% of layout needs) On top of that I've have near 200 (and counting) abolutely application custom made components (editors, headers, toolbars, more creative widgets of our own, etc) they often have intense DOM interaction between them and are allways loose coupled using announcements (at server) and #fire: (at DOM). So I'm sure anyone capable of *using* MVP to develop desktop apps will love to use this beacause the barrier to scale that apps to web are lowered to a minimum. Cheers, Sebastian _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Design of WAComponent(s)
|
|
In reply to this post by Ramon Leon-5
> -----Mensaje original----- > De: [hidden email] > [mailto:[hidden email]] En nombre > de Ramon Leon > Enviado el: Jueves, 06 de Marzo de 2008 14:20 > Para: 'Seaside - general discussion' > Asunto: RE: [Seaside] Design of WAComponent(s) > > > No offense please but some answers show a lack of > > appreciation for the users of Seaside. If you want to grow > > the users base of Seaside, you need to answer the question of > > Microsoft. If you dont, it will remain a great tool from > > specialists for specialists. And fade in oblivion eventually. > > Why? Emacs and Vi do pretty well as editors without catering > to newbies, > why the assumption that building tools for experienced programmers is > somehow fatal? Seaside is a framework, not a component library. > I'm happy to use ubuntu (with NXServer) is not to need vi anymore to fill my expensive cerebral RAM with exotic key combinations (used once a while) of software not designed to respect basic design principles not to mention human beings heuristics. I hope Seaside NEVER take a path which make it comparable to that kind of software. I mean never ever to the end of time I'm sure you know technology should be meant to deconstruction of the barriers of dominating things (machines) to do the human's will and not to build new barriers or keep them. Doing that reveals the developer's established statu quo of that epoch which IMHO is nothing more than a small mediocre thought none here should have (among other things because how Smalltalk has born). > > > I do not have the skills and time of lukas to create > > widgets from scratch. > > > But I imagine that I should be able to reuse them. > > > > Chapeau! That *IS* the main point. Those non-specialist that > > might be attracted to Seaside and Smalltalk are very likely > > not fluent in the details of XHTML, Java-script and AJAX. > > Asking them to create new components from the given examples > > will end in bad copy&paste programming. > > How does that have anything to do with whether the core > should or shouldn't > include generic components? No one is saying reusable > components are bad, > look at ShoreComponents, that is how generic components > should be done, as > separate packages that don't bloat the core framework. It'd > be great to > have a wide variety of component options, no one disputes > that, they just > don't belong in the core framework. > of. I'm happy with the taken path for 2.9. In any case Seaside must care for the interest of the better preserve and mature the good platform it is. The things we create *on* it are just talking about the richness it provides. Something good can grow from it beacouse is a solid fundation. Cheers, Sebastian > BTW, anyone not fluent in the details of XHTML, Javascript > and AJAX isn't > going to make it very far in *any* web framework. If you > want to develop > web applications, these things are pretty much required > learning. Seaside > may let you write XHTML, Javascript, and Ajaxy stuff in > Smalltalk syntax, > but you still have to understand them to make effective use of those > abstractions. There's no getting around that. > > Ramon Leon > http://onsmalltalk.com > _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
> You mean the point is Seaside must apply as a Vi kind of
> tool? No, Vi was just an example. My point is it's a false assumption that every program *must* be friendly to newbs to be successful or worth using. Not that Seaside is that difficult, but the goal shouldn't be trying to hand hold people who don't know anything about web development, Javascript, or Ajax and try and make web developers out of them. The goal is a better web framework for *web developers*. If you don't know much about web development, you've got things you need to learn before you pick up Seaside. > > core framework. It'd be great to have a wide variety of component > > options, no one disputes that, they just don't belong in the core > > framework. > > > This very important. None is questioning what the core of > Seaside has to be made of. I'm happy with the taken path for > 2.9. In any case Seaside must care for the interest of the > better preserve and mature the good platform it is. > The things we create *on* it are just talking about the > richness it provides. > Something good can grow from it beacouse is a solid fundation. > > Cheers, > > Sebastian And that's the main point, Seaside is the foundation, it's not supposed to be the ultimate component library nor should it try to be, that's not what frameworks are for. Frameworks serve as the foundation of such libraries. Ramon Leon http://onsmalltalk.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Design of WAComponent(s)
|
|
Come on.
I'm far from a newbie (at least I believe it) and this is boring to develop from scratch the same. I imagine that lot of people reuse their own component. When I write a desktop app, I'm not a newbie still I like to reuse window, buttons and label. At least I'm not interested in knowing how scrollbar and other details work. Where is the newbie here? Why people like to take extreme statements. On Mar 6, 2008, at 7:25 PM, Ramon Leon wrote: >> You mean the point is Seaside must apply as a Vi kind of >> tool? > > No, Vi was just an example. My point is it's a false assumption > that every > program *must* be friendly to newbs to be successful or worth using. > > Not that Seaside is that difficult, but the goal shouldn't be trying > to hand > hold people who don't know anything about web development, > Javascript, or > Ajax and try and make web developers out of them. The goal is a > better web > framework for *web developers*. If you don't know much about web > development, you've got things you need to learn before you pick up > Seaside. > >>> core framework. It'd be great to have a wide variety of component >>> options, no one disputes that, they just don't belong in the core >>> framework. >>> >> This very important. None is questioning what the core of >> Seaside has to be made of. I'm happy with the taken path for >> 2.9. In any case Seaside must care for the interest of the >> better preserve and mature the good platform it is. >> The things we create *on* it are just talking about the >> richness it provides. >> Something good can grow from it beacouse is a solid fundation. >> >> Cheers, >> >> Sebastian > > And that's the main point, Seaside is the foundation, it's not > supposed to > be the ultimate component library nor should it try to be, that's > not what > frameworks are for. Frameworks serve as the foundation of such > libraries. > > Ramon Leon > http://onsmalltalk.com > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |