Hi Jim!

I'm sorry about the problems with the changes to the border system 
(BorderPresets).

To the documentation issue. Yes I think it's true, that each change 
requires additional work for the writers of documentation. But this is 
also true for the switch between major release to major release. I don't 
know a nice solution for this in a highly active project like qooxdoo.

Cheers,

Sebastian


Jim Hunter schrieb:
> I agree with everyone so far. New development should not be to make 
> things harder, it should be to make things easier for the other 
> developers. More shortcuts should be added off the root of each control 
> to hide the complexity of the control from the developer.
> You are asking that everyone contribute to the documentation and many 
> have jumped in head first and are doing a great job at it. But if you 
> keep changing the API, the documentation they are creating will be for 
> not. A quick example would be the borders. My application was working 
> fine and if I had written a bunch of docs on how to create and use 
> borders, my docs would have been rendered useless a couple of days ago 
> when the borders API was changed. All of a sudden, I had a flat app with 
> no borders. I had to look through code to figure out what changed and 
> then go into my code and make all the changes just to get back to where 
> I was. I didn't see any real reason for the change.
> So making API changes effects not only developers but all the people you 
> have writing docs for you. When we get to a release point for .6, there 
> will be no way to know if the docs are correct if you keep changing the 
> API along the way. Even a tiny change will cause programs to stop 
> working and already written documentation to erroneous.
> 
> Just my $.02
> 
> Thanks,
> Jim
> 
> On 8/16/06, *Christian Boulanger* <[EMAIL PROTECTED] 
> <mailto:[EMAIL PROTECTED]>> wrote:
> 
>     Hi, I would support Derrell.
> 
>     I have already said that the "moving target" nature of qooxdoo creates
>     many problems for developers to build applications along with the
>     development. Yes, I know it is not 1.0 and yes, I recognize the need for
>     optimization etc. etc. and lastly, I do recognize that the main
>     developers
>     need to work efficiently and cannot discuss everything... but I would be
>     extremely careful about API changes that break other people's existing
>     application (If that is the case, I don't know).
> 
>     It would be less of a problem if you keep the API by internal
>     shortcuts -
>     you could add a function that marks the API call as deprecated while
>     still
>     maintaining funtionality. This could be cleaned up later.
> 
>     But most importantly, I support Derrels point to keep function names as
>     short as possible and not get too enthousiastic about the namespace
>     model.
>     Javascript is not Java. If you provide shortcuts from the qx root or at
>     most from qx.foo, I'd be more convinced...
> 
>     Christian
> 
>      > [EMAIL PROTECTED]
>     <mailto:[EMAIL PROTECTED]> writes:
>      >
>      >> -    qx.core.Init.defineMain(function() {
>      >> +    qx.core.Init.getInstance().defineMain(function() {
>      >
>      > Sebastian, I've been looking at your numerous recent singleton
>     changes
>      > which
>      > affect every application and developer of qooxdoo.  You are
>     adding levels
>      > of
>      > indirection that are entirely superfluous, for the sole purpose,
>     it seems,
>      > of
>      > making it more difficult for the developer to use qooxdoo.  We
>     should be
>      > providing ways to REDUCE the number of internal class references
>     needed to
>      > be
>      > known by the user, not INCREASE them as you're doing.
>      >
>      > Instead of changing from
>      >   qx.core.Init.defineMain()
>      > to
>      >   qx.core.Init.getIntance().defineMain()
>      >
>      > if we're going to make a change at all, it  should be something more
>      > towards
>      >   qx.defineMain()
>      > not the other way around as you've done.
>      >
>      > Similarly for all (hundreds?) of the other classes that you
>     changed to add
>      > a
>      > requirement for a getInstance() call.
>      >
>      > I don't believe that there was anything wrong with the previous
>     method of
>      > creating singletons, and it was much easier for the user to work
>     with than
>      > having to call getInstance() each time.  In fact, there's no
>     reason for
>      > the
>      > user to even have to know, in many (most?) cases, that he's
>     working with a
>      > singleton.
>      >
>      > PLEASE, PLEASE, PLEASE "discuss" before "doing".  Big changes
>     like this
>      > should
>      > not be a one-person decision, particularly when it effects each
>     and every
>      > qooxdoo application and developer like this does.
>      >
>      > Developers, please chime in here.  If you all think that these
>     changes are
>      > "good", "useful" and/or "necessary", say so.  If you think that
>     this is
>      > going
>      > in the wrong direction, we need to hear that too.  Maybe I'm not
>     speaking
>      > for
>      > the community, so let's hear from y'all.
>      >
>      > Cheers,
>      >
>      > Derrell
>      >
>      >
>     -------------------------------------------------------------------------
>      > Using Tomcat but need to do more? Need to support web services,
>     security?
>      > Get stuff done quickly with pre-integrated technology to make
>     your job
>      > easier
>      > Download IBM WebSphere Application Server v.1.0.1 based on Apache
>     Geronimo
>      >
>     http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>     <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642>
>      > _______________________________________________
>      > qooxdoo-devel mailing list
>      > [email protected]
>     <mailto:[email protected]>
>      > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>      >
> 
> 
> 
>     -------------------------------------------------------------------------
> 
>     Using Tomcat but need to do more? Need to support web services,
>     security?
>     Get stuff done quickly with pre-integrated technology to make your
>     job easier
>     Download IBM WebSphere Application Server v.1.0.1 based on Apache
>     Geronimo
>     http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>     <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642>
>     _______________________________________________
>     qooxdoo-devel mailing list
>     [email protected]
>     <mailto:[email protected]>
>     https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>     <https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel>
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply via email to