On 2006-09-18, at 09:48 EDT, Hogarty, David A. wrote: > I think you missed my meaning. I'm familiar with the capabilities > described in the blog post. What I'm looking to do is to be able to > modify EXISTING internal views in the instantiation, whereas > currently you can only add new views. If you look at the example > again, I'm trying to attach a new event to an existing internal > view. This allows better code reuse, e.g. a generalized form with > customizeable submit actions, etc. Possible syntaxes for this new > capability are shown below: > > <class name="foo"> > <view name="a" /> > <button name="b"> > <view name="c" /> > </button> > </class> > > <!-- new event selection syntax using a javascript expression under > the class context --> > <foo> > <method event='this.b.onclick'> > //some code > </method> > </foo>
This should work in the current system. You are allowed to add methods to instances. The [modern](http://wiki.openlaszlo.org/ Event_and_handler_tags) syntax is to say: <foo> <handler name="onclick" reference="this.b"> ... </handler> </foo> > <!-- full modification of previously defined attributes and > internals --> > > <foo> > <modify name="a" onclick="somexpression" bgcolor="somecolor" /> > <modify name="b.c"> > <view "d" /> > </modify> > </foo> The full generality you propose here is not supported. This is partly due to the tension between making classes completely malleable and making code extremely fragile. For each of the features you modify in your example, with the cooperation of the class designer you could have the ability to make the changes you propose in your instance. To override an event, the class designer has to expose the event handler: <class name="foo"> <handler name="onclick" method="handleOnClick" /> <method name="handleOnClick> ... </method> </foo> Then in subclasses or instances you can override handleOnClick. Similarly, to change the background color, you can expose it as an attribute: <class name="foo"> <view name="a" bgcolor="${aColor}" /> <attribute name="aColor" value="blue" /> </foo> In both these cases, if the class designer wants to permit overriding of features, they need to expose it in an overridable way, either as a method or an attribute. I think providing a general way to access the internals of classes in LZX is an interesting idea, but it seems inconsistent with the simplicity goals of LZX. In the case of adding view, you can use the `placement` attribute to achieve what you want: <foo> <view name="d" placement="c" /> </foo> I know this doesn't answer your question, but maybe there is more flexibility here than you were aware of. We should keep exploring this area, because I know that you are not the only one who has had this issue. Many times people want to repurpose a component, and currently the only way to get all the flexibility that you might need is to either a) re-implement the component, exposing new API's, or b) copy the source and fork the component. Neither of these is a great choice. Aspect-oriented programming is an approach that is used in other O-O languages to achieve these goals. Perhaps there is something from that discipline that could be adopted to LZX. Finally, we are putting the finishing touches on a new CSS implementation that will go a long way to solving at least _some_ of the issues with component reuse, although that still will require forethought by the class designer to make the correct attributes of their class styleable. > As alluded to in my previous post, you can achieve these same goals > using javascript (in the oninit event, not the onconstruct like I > used in the example, because internal views need to have already > been constructed to be referenced), but the syntax is ugly and it > requires too deep a knowledge of lazlo for the average user. > > -Dave > > -----Original Message----- > From: P T Withington [mailto:[EMAIL PROTECTED] > Sent: Sat 9/16/2006 9:12 AM > To: Hogarty, David A. > Cc: Not Zippy; James Howe; [email protected] > Subject: Re: [Laszlo-user] Code Refactoring? > > On 2006-09-15, at 17:39 EDT, Hogarty, David A. wrote: > >> On this same note, I think it would be beneficial to allow post- >> definition modification of a classes internal views at >> instantiation, for example: >> >> <class name="foo"> >> <view name="a" /> >> <button name="b" /> >> </class> >> >> >> <foo> >> <method event='this.b.onclick'> >> //some code >> </method> >> </foo> >> >> >> Can we already do something like this? > > Yes. See this nifty blog entry of Oliver's on [instance-first > development](http://osteele.com/archives/2004/03/classes-and- > prototypes). > > _______________________________________________ Laszlo-user mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-user
