> Yes, but again I think that using XML to describe the widgets should be > the aim. This would also mean that you can exchange GUI templates with > other backends implemented in other languages. I cannot sing the praise > enough of TAL which is used in the Zope server and has implementations > in other languages. It enables me to build dynamic widgets on the server > side which are very transparent.
I agree that we should have a layer on the server that uses XML to describe the qooxdoo application. We can then write converters to the qooxdoo js for several languages. How we arrive at the XML should also be flexible. At times you may want to code the XML by hand directly. Other times you may want to use TAL or have XML generated based on other application logic. > Yes you are right. A framework should be unobstrusive. On the other > hand, if everything comes out-of-the-box and allows you to just throw in > some data describing the widgets and some code delivering the data in > raw form (without the need to think about transport, validation, > security etc.) - this might be come very handy for developers (at least > for me, I would love to have it!). I think that this is the ultimate goal. It takes a lot of work to get there. My framework does most of this now for traditional HTML websites, but it only takes my rerquirements into account (which apply to other applications in most part but not everything). To make this a viable open source project I have to revisit the module architecture again to ensure that any developers can easily contribute their own modules. It is also essential that we can take from other open source projects what we need. For instance if one project has a really good server side validation API for forms I would want to use that in my framework so that the existing community for the validation can keep advancing it while I use it through a standard interface in my framework. The task of documenting and supporting a comprehensive framework is huge. Especially when you cannot do it full-time. So instead of trying to change the world in one day I was thinking to release one small component at a time that anyone can use within most existing frameworks. That way community can start to build around each component and steer it in the most useful way. I would not re-create the qooxdoo API on the server with the goal of having it identical to the client side. The naming of major features may be the same initially to keep it consistent with the JS side but over time there would be a whole bunch of additional functionality that would allow you to build qooxdoo application using templates, inheritance of meta objects etc... It is imperative that whichever way we go with this that if a developer needs a feature of qooxdoo that we have not addressed yet explicitly that they have a low-level API or XML syntax they can turn to until we have abstracted it. This way they can start using our codebase right away instead of waiting until we have every feature abstracted. > I would certainly join this project given it can do what I need or if I > can quickly add what I need. Thats great to hear. I'll keep you posted. For now maybe you can help me with the PHP/qooxdoo part. Christoph -- View this message in context: http://www.nabble.com/Increase-exposure-awareness-with-visible-project-t1360587.html#a3729414 Sent from the qooxdoo-devel forum at Nabble.com. ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
