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 = this.element.nodeType;
                                this.tagName = this.element.tagName;
                                this.delegateMethods();
                        },
                        delegateMethods : function(){
                                var methods = Element.Methods;
                                for(var method in methods){
                                        var __method = methods[method];
                                        if (Object.isFunction(__method) && 
!(__method in this))
                                                this.assignMethod(method, 
__method);
                                }
                        },
                        assignMethod : function(method, __method){
                                this[method] = function(){ return 
__method.apply(this.element,
[this.element].concat($A(arguments))); };
                        }
                });

--

http://positionabsolute.net

On Oct 16, 3:01 pm, Matt Foster <mattfoste...@gmail.com> wrote:
> 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 reference.  As long as the
> ElementProxy class implements all the regular methods then core
> prototype processes wouldn't know the difference between the two.
>
> --
>
> http://positionabsolute.net
>
> On Oct 16, 12:02 pm, Eric <lefauv...@gmail.com> wrote:
>
> > 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 (and keeping it
> > in an attribute) (*)
> > - implement the toElement() method in the class (to return this DOM
> > element) (*)
>
> > The second step allows you to provide your class instance to any
> > prototype method instead of a DOM element.
> > A small example:http://jsbin.com/omaza
>
> > Ooooops: Previous sentence was wrong... After trying to write the
> > example, and checking in the source, it seems that you can only use
> > this kind of object as a DOM element in a handfull of prototype's
> > methods (insert, update and replace)...
>
> > Is it any reason why this behavior is not implemented in $() (this
> > would actually allow to use a custom class everywhere where a DOM
> > element is needed, and just add one line of code).
>
> > Eric
>
> > (*) This was the simplest way to explain the process, but you may
> > prefer dynamically create the DOM element on the first call of
> > toElement() for better efficiency.
> > On Sep 10, 10:56 am, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
>
> > > 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 ways in two different panels (in a list, for
> > > instance, and in a details pane that shows the details of the
> > > highlighted object in the list), you can't, or rather the code gets
> > > ugly fast.
>
> > > Instead, I'd suggest keeping the business object separate from the
> > > element and using a "has a" rather than an "is a" relationship.  You
> > > can do that by storing the business object ID on the element in some
> > > way ("data-key" is the attribute I usually use for this, and fits with
> > > the proposed HTML5 data attributes standard), either directly or via a
> > > small controller.
>
> > > The business object should never update the element directly, and so
> > > it doesn't need to know about it.  Instead, it should raise events
> > > that controllers can respond to by updating the elements they
> > > control.  When I say "fire event," I'm not necessarily talking
> > > browserspeak (I wouldn't use browser events for this), just a minimal
> > > implementation of the Observer pattern (as a mixin or similar you can
> > > use for lots of different objects).
>
> > > FWIW, and apologies if I went OT, but I hope I didn't,
> > > --
> > > T.J. Crowder
> > > tj / crowder software / comwww.crowdersoftware.com
>
> > > On Sep 9, 3:02 pm, Andrea Campi <andrea.ca...@gmail.com> wrote:
>
> > > > Hi,
>
> > > > in my application I need JS objects to represent some "business"
> > > > objects, which are represented on the page by an Element.
> > > > I would like to be able to tie the two together in such a way that I
> > > > can use them interchangeably.
> > > > This sounds like it should be a common pattern, so I was wondering
> > > > what the best practices are.
>
> > > > Example:
>
> > > > var Foo = Class.create({
> > > >   initialize: function(parent) {
> > > >     var element = Object.extend(new Element("div", { 'class': 'foo',
> > > > 'id': 'myFoo' }), this);
> > > >     parent.insert(element);
> > > >   },
>
> > > >   bar: function() {
> > > >   }
> > > >   // more methods
>
> > > > };
>
> > > > Thanks to Object.extend I can easily call: $('myFoo').bar()
> > > > But I cannot do the opposite, for instance:
>
> > > > var foo = new Foo();
> > > > foo.childElements();
>
> > > > Note that it would just work if I could return 'element' (which now
> > > > behaves like Foo).
> > > > However, I've readhttp://dev.rubyonrails.org/ticket/11481andithas
> > > > reasonable objections to letting the constructor return a value.
>
> > > > So, what gives? Any suggestion?
>
> > > > TIA,
> > > >   Andrea
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to 
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to