Brush or Component?
Locked
 
|
Hi,
I'm planning to wrap a date picker (http://www.dynarch.com/projects/calendar/), what is the best approach I should take? Use it as a brush, make it a full featured component, or use both? Is it possible to automatically reference the required css/js when this wrapper is used, or must be defined explicitly in the containing component? Best regards, -- Esteban A. Maringolo [hidden email] _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Hi Esteban,
to know if it's possible to make a full component you should know how much you can control of it (will have you access to it's sources? Only an api?). I would think in evaluating the convenience of it "wrappeability" before anything. About your second question, aren't you using css/javascript external files? Are you really planning to serve css with comanche/swazoo instead apache, etc? I think in a component, problbly wrapped by a div, that just has the css classes it needs and are defined in detail in the css file. cheers, Sebastian Sastre > -----Mensaje original----- > De: [hidden email] > [mailto:[hidden email]] En nombre > de Esteban A. Maringolo > Enviado el: Lunes, 28 de Enero de 2008 11:41 > Para: Seaside - general discussion > Asunto: [Seaside] Brush or Component? > > Hi, > > I'm planning to wrap a date picker > (http://www.dynarch.com/projects/calendar/), what is the best > approach I should take? > Use it as a brush, make it a full featured component, or use both? > > Is it possible to automatically reference the required css/js > when this wrapper is used, or must be defined explicitly in > the containing component? > > Best regards, > > -- > Esteban A. Maringolo > [hidden email] > _______________________________________________ > 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 |
|
|
In reply to this post by Esteban A. Maringolo
2008/1/28, Esteban A. Maringolo <[hidden email]>:
> Hi, > > I'm planning to wrap a date picker > (http://www.dynarch.com/projects/calendar/), what is the best approach > I should take? > Use it as a brush, make it a full featured component, or use both? > > Is it possible to automatically reference the required css/js when > this wrapper is used, or must be defined explicitly in the containing > component? Depends on the markup. If it is only one html element a subclass of WATextInputTag might be the way to go. If you have more than one html element use a component. The css has to be included in the root somehow. All the standard ways are possible here altough doing it in #updateRoot: of your date picker component (if you decided to go with a component) will probably include it several times if you have the component multiple times on the "page". You might want to avoid this. Cheers Philippe > Best regards, > > -- > Esteban A. Maringolo > [hidden email] > _______________________________________________ > 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 |
|
|
In reply to this post by Esteban A. Maringolo
Hi!
There is already a Date Picker (SUDatePicker) in Seaside 2.9 using Scriptaculous!
Maybe it is what you are looking for.
In this case its a component (subclass of WAMiniCalendar)
br
Gerhard
2008/1/28, Esteban A. Maringolo <[hidden email]>:
Hi, _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Good news. Controls use to be kind of expensive
creatures.
cheers!
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Gerhard Obermann
Gerhard Obermann wrote:
> Hi! > > There is already a Date Picker (SUDatePicker) in Seaside 2.9 using > Scriptaculous! > Maybe it is what you are looking for. > In this case its a component (subclass of WAMiniCalendar) Speaking of components, is there a list somewhere as to what components (see woodstock java project) are available? Cheers from Europe, Claus _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
2008/1/29, Claus Kick <[hidden email]>:
> Gerhard Obermann wrote: > > Hi! > > > > There is already a Date Picker (SUDatePicker) in Seaside 2.9 using > > Scriptaculous! > > Maybe it is what you are looking for. > > In this case its a component (subclass of WAMiniCalendar) > > Speaking of components, is there a list somewhere as to what components > (see woodstock java project) are available? No, simply because the componentens included are not meant for production. Cheers Philippe > Cheers from Europe, > > Claus > _______________________________________________ > 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 |
|
|
In reply to this post by Philippe Marschall
On Jan 28, 2008 4:05 PM, Philippe Marschall
<[hidden email]> wrote: > 2008/1/28, Esteban A. Maringolo <[hidden email]>: > > Hi, > > > > I'm planning to wrap a date picker > > (http://www.dynarch.com/projects/calendar/), what is the best approach > > I should take? > > Use it as a brush, make it a full featured component, or use both? > > > > Is it possible to automatically reference the required css/js when > > this wrapper is used, or must be defined explicitly in the containing > > component? > > Depends on the markup. If it is only one html element a subclass of > WATextInputTag might be the way to go. If you have more than one html > element use a component. Actually, it is one element someway. It is an element (textinput) and a button/image which triggers the javascript. After trying different approaches, now the brush approach seems to be the best, because it can be used by separate, or for a customized magritte editor component. Regards, -- Esteban A. Maringolo [hidden email] _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Hi,
By now, the brush approach is fine. I subclassed WACompound and it's working. But if I want to add event handlers (onChange/onClick/etc.), I can't do it, because it's only defined in WATagBrush. My compound has only one element, and fits better to be a compound than a tag (which in fact it isn't). I can add the required handlers to be passed to one of the compound children, or even make a common superclass for all the brushes sharing this behavior and structure, but I'm sharing this here, to know if somebody had the same situation or found a better solution. Best regards, -- Esteban A. Maringolo [hidden email] _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Thanks for sharing. I can tell that I'm as much component centric for web
elements as object centric for smalltalk, cheers, Sebastian Sastre > -----Mensaje original----- > De: [hidden email] > [mailto:[hidden email]] En nombre > de Esteban A. Maringolo > Enviado el: Miércoles, 30 de Enero de 2008 15:00 > Para: Seaside - general discussion > Asunto: Re: [Seaside] Brush or Component? > > Hi, > > By now, the brush approach is fine. I subclassed WACompound > and it's working. > But if I want to add event handlers (onChange/onClick/etc.), > I can't do it, because it's only defined in WATagBrush. > > My compound has only one element, and fits better to be a > compound than a tag (which in fact it isn't). > > I can add the required handlers to be passed to one of the > compound children, or even make a common superclass for all > the brushes sharing this behavior and structure, but I'm > sharing this here, to know if somebody had the same situation > or found a better solution. > > Best regards, > > -- > Esteban A. Maringolo > [hidden email] > _______________________________________________ > 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 |
|
|
On Jan 30, 2008 2:07 PM, Sebastian Sastre <[hidden email]> wrote:
> Thanks for sharing. I can tell that I'm as much component centric for web > elements as object centric for smalltalk, For some simple "elements" such this, the frontier between using a brush or a component is fuzzy to me[*]. In this case, using a brush makes it easier to reuse inside a magritte editor component, stand alone, or inside another component. Am I thinking too much MVC/MVP in Seaside? Best regards, [*] I know you worked with Dolphin Smalltalk, and it is like the ambiguity between a Presenter or a ValuePresenter, or even on defining a new view class or compose a new view resource. This is until you really understand the MVP approach. -- Esteban A. Maringolo [hidden email] _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
> For some simple "elements" such this, the frontier between
> using a brush or a component is fuzzy to me[*]. > In this case, using a brush makes it easier to reuse inside a > magritte editor component, stand alone, or inside another component. > Maybe it works (I mean in term of development costs here) when using magritte I really can't say. > Am I thinking too much MVC/MVP in Seaside? > No more than me ;) and happily I'm reusing components/code agresively because of that. > Best regards, > > [*] I know you worked with Dolphin Smalltalk, and it is like > the ambiguity between a Presenter or a ValuePresenter, or > even on defining a new view class or compose a new view > resource. This is until you really understand the MVP approach. > > -- > Esteban A. Maringolo > [hidden email] > _______________________________________________ It's curios you mention that, in fact I'm using value models in some value presenters that are a seaside kind of component I've made to mimic the Dolphin's way. It's very cool be able to do that. cheers, Sebastian _______________________________________________ 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 |