Yeah that'd be great functionality to allow for a much simpler proxy
On Oct 19, 9:48 am, Eric lefauv...@gmail.com wrote:
Matt,
I like your way of doing it, but my concern is that the documented
toElement() method seems to be only half implemented.
A minor change to the $() function could
Matt,
I like your way of doing it, but my concern is that the documented
toElement() method seems to be only half implemented.
A minor change to the $() function could make it work completely (see
it here: http://pastie.org/660553 ).
What do you guys think about this change?
Eric
On Oct 17,
Hi,
While I agree with T.J. arguments, there are cases when it is nice to
have this behavior (DOM element and Plain object in the same
object). On of those case is, for example when you're creating a new
control class.
The way I do it is:
- building the DOM element in the class's constructor
The has a relationship is the only way to go for sure.
You could create an ElementProxy class that inherits all the Element
methods but just keeps a reference to the actual DOM reference
internally. All of the Element.Methods are parameterized so I'm sure
there'd be an easy way to delegate the
Quick and dirty, im sure there are errors but conceptually this would
be my approach...
var ElementProxy = Class.create({
initialize : function(ele){
this.element = $(ele);
this.nodeType =
Hi Andrea,
FWIW, I'd say the best practice is: Don't do that, it conflates the
model with the view *and* the controller. :-) (MVC is not by any
means the only game in town, but the terminology is useful for
questions like this.) If you ever want to present the business object
in two different
