I add both fields and methods to base classes. Here is an example of one of the methods that I use all over my application (I use the disposeChildren() function everywhere to remove objects from the system as removeAll() does not work as detailed in many posts):

qx.Proto = qx.OO.classes["qx.core.Object"].prototype;
qx.Proto.hasChildren = function()
{
  // this gives a basic result for widgets like Labels that don't have this function
  // I feel ALL classes should have this method
  return false;
}
qx.Proto.getChildren = function()
{
  // this helps with some classes that have problems with this method, may not be needed in the future.
  s = new Array(); // return an empty array
  return s;
}
qx.Proto.disposeChildren = function()
{
  //mainWin.info(this.classname);
  try
  {
   if (this.hasChildren() == true)
   {
     this.forEachChild(function()
       {
         this.disposeChildren();
         this.setParent(null);
         this.dispose();
       }
    )
   }
  }
  catch(e)
  {
    // qx.ui.table.Table always fails on hasChildren so ignore it.
  }
}

Notice that I am modifying the base class, there is no way I can subclass and get the same results. The only way a change will work is that the change include these methods in the base class. I agree with Christian in that I do not want to maintain my own branch of the trunc in order have my own code added in and maintain my own builds. I would rather use the release versions of qooxdoo and add additional functionality from my own file at runtime. I don't care if the way to add a method gets changed as long as I can still add methods to base classes. I have no problem changing my user fields of base classes to use the userData way, no big deal, but if you take away my ability to add methods to base classes you are making me code with my hands tied behind my back. While you are making changes, keep this one thing in mind... not all problems can be solved by subclassing!

Thanks,
Jim


On 9/25/06, Sebastian Werner <[EMAIL PROTECTED]> wrote:
Hi Christian,

please explain what are your exact use cases. Do you just add properties
e.g. IDs etc. or do you even modify them? To you attach modifiers? Do
you do this on instance level or on prototype level?

Cheers,

Sebastian


Christian Boulanger schrieb:
> Hi Sebastian,
>
> thanks for your input. I can only speak for myself, but my interest as
> developer is to work with the existing classes instead of subclassing
> them as new ones. This is much more flexible and allows me to extend the
> behaviour of my application without having to rewrite a single line of
> the gui code or having to change qooxdoo source code and get out of sync
> with SVN etc. I think this is a valid concern even if some purist might
> shudder. Not everyone has the time to do things like in the text book,
> and we shouldn't force _javascript_ to behave like a class-based language.
> Run-time property addition is a great tool to solve real problems.
>
> So if you have good ideas for optimizing the property system, that's
> excellent. But I would ask you to create a parallel (slower) system
> which allows to override custom behaviour in "the old way".
>
> Thanks,
>
> Christian
>
> Sebastian Werner schrieb:
>> OK, lets me explain the benefits of this new version, when it comes, and
>> let us find solutions for your needs. Sometimes it's not the best
>> solution to try to keep an existing system, especially when they have
>> some design issues. It might be better to reinvent the wheel in some
>> cases. And we definitely try to find a way to solve the requirement of
>> custom properties, but this does not mean these must be real properties,
>> like previously known from qooxdoo.
>>
>> OK, let's begin. The reason for this new system would be a dramatically
>> better performance. The old system was somewhat over-engineered and
>> expensive. We need a system which scales as well as self-written
>> setters/getters. But we want this as comfortable and easy as previously.
>> The idea behind the new system is to do the things as lazy as possible.
>> The system also used advanced caching features to omit the double
>> creation of stuff. It will generate setters, which are highly tuned and
>> so use the optimal code, to do exactly what was defined by the
>> developer. It's the best code for this property, comparable with
>> hand-written code for each function. Also it's much easier possible to
>> reconfigure properties with the inheritance e.g. changing types, default
>> values, ...
>>
>> The only negative point would be, that it's not possible to change or
>> add properties after the first instance of the object has been created.
>> I think this is OK for real properties, but we definitely need a way to
>> let the non-framework developers attach data comparable to the old way.
>>
>> Details for this new system will be showed off in a few months. These
>> are just the first signs of the new API. Nothing finalized yet.
>>
>> Maybe there are already ideas for a better system - from the users view
>> (user data). Would it be enough to add validation, like in the current
>> properties, to the user data stuff? Do you need the event support for
>> your custom fields? We are open for discussion. Please place in your
>> ideas. Hopefully the results will be a good choice for all developers.
>>
>> Cheers,
>>
>> Sebastian
>>
>>
>>
>>
>> Christian Boulanger schrieb:
>>
>>> Sebastian Werner schrieb:
>>>
>>>> <snip>
>>>> I just mention this, because this will not work in the future. The plans
>>>> for a new property system doesn't allow the dynamic addition of
>>>> properties to previously defined classes.
>>>>
>>>> Maybe it's better to enhance the other properties to make it possible to
>>>> use them in a comparable way.
>>>>
>>>>
>>> That's bad news! What would be the possible benefit? If that is the
>>> plan, this completely throws my migration plans out of the window. I am
>>> dependent on the ability to migrate the QxDataManager extensions, and
>>> the only way they will work is through the excellent existing system. I
>>> don't think native qooxdoo will ever support what QxDataManager does, so
>>> no new feature that you want to implement by abandoning run-time
>>> property additions can outweigh this.
>>>
>>> I would strongly suggest asking the userbase whether your idea is really
>>> welcome - I would consider this, by the way, good practice for any such
>>> far-reaching change. I personally would really regret it. These are my
>>> two cents.
>>>
>>> Cheers,
>>>
>>> Christian
>>>
>>>
>>>
>>> -------------------------------------------------------------------------
>>> Take Surveys. Earn Cash. Influence the Future of IT
>>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>>> opinions on IT & business topics through brief surveys -- and earn cash
>>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>> _______________________________________________
>>> qooxdoo-devel mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>>>
>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>> opinions on IT & business topics through brief surveys -- and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> qooxdoo-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply via email to