qooxdoo / PHP framework project

[Oliver Vogel-2]

> I think the main value of using XUL is to borrow from a standard that has
>many UI-related challenges solved using standard patters as Ben mentioned.
>There are also a host of tools starting to spring up to edit XUL
>definitions. Even visual drag and drop tools to design UI's.
>  
>
only for my personal interrest - can you send me a link to a UI-deisgner
creating XUL?

>Using the QxBuilder syntax will work, but it may get pretty verbose when you
>start to link many components together with events.
>
>Do we have to have the XUL engine on the client side? It would be ideal, but
>it would further slow down loading of qooxdoo apps. Can we not implement a
>server component that will take the XUL definition and generate all
>necessary javascript that qooxdoo will need and simply have qooxdoo load it
>into its context. I can write such a converter initially in PHP pretty
>quickly.
>

i think, this may be a good idea

>There would be a client javascript component to it as well that
>will call event callbacks with a context more comprehensive than qooxdoo
>currently provides with its event system.
>  
>
what is the problem of the event system used in qooxdoo?

>This comes back to the question of how qooxdoo code should be defined to
>maximize speed of loading. Is the API the fastest way or would it be faster
>to load some king of internal structure?
>  
>
i think, we can use my class (maybe a rewritten class but like mine) and
we should use the API (maybe i am wrong, but i think, this is easier to
debug.

Olli

>Christoph
>
>
>
>
>--
>View this message in context: http://www.nabble.com/qooxdoo-PHP-framework-project-t1389226.html#a3768945
>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
>Qooxdoo-devel@...
>https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>  
>

-------------------------------------------------------
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
Qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[ChristophDorn]

> only for my personal interrest - can you send me a link to a UI-deisgner creating XUL?

When I was researching this I found one, but cannot remember the link.
Here is a dead one http://xulmaker.mozdev.org/
If you find one that is actively being developed let me know.


> what is the problem of the event system used in qooxdoo?

There is nothing wrong with the qooxdoo event system itself. It just needs a wrapper so we can keep more detailed object context and have the ability to easily query the server.


> i think, we can use my class (maybe a rewritten class but like mine) and
> we should use the API (maybe i am wrong, but i think, this is easier to
> debug.

Your calss determines which objects qooxdoo needs. What I am refering to is how the qooxdoo application should be initialized. If we can condense the initialization javascript code (that adds all the components and event listeners...) into a more low-level structure it may speed up loading even more.

Christoph

[Ben Alex-5]

ChristophDorn wrote:
> If you find one that is actively being developed let me know.
>
>  
Lots of XUL-related links (including to books) are at
http://xul.sourceforge.net/. Also, http://xulblog.de/xul/ has some
interesting links, including to an ActiveX control that embeds the Gecko
rendering engine, making XUL available to Internet Explorer.

Cheers
Ben



-------------------------------------------------------
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
Qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[panyasan]

ChristophDorn schrieb:
>  I think the main value of using XUL is to borrow from a standard that has
> many UI-related challenges solved using standard patters as Ben mentioned.
> There are also a host of tools starting to spring up to edit XUL
> definitions. Even visual drag and drop tools to design UI's.
>  
Ok, I agree on this. Being able to use GUI builders would be great.
> Using the QxBuilder syntax will work, but it may get pretty verbose when you
> start to link many components together with events.
>  
But here comes the problem: with your XUL2QX parser, you need to map all
the attributes of XUL to those of Qx and still after that, the
javascript working with the widgets doesn't correspond to the XUL model.
Isn't that a major drawback?
> quickly. There would be a client javascript component to it as well that
> will call event callbacks with a context more comprehensive than qooxdoo
> currently provides with its event system.
>  
I assume this is where you would have to map all events, methods and
properties. This seems to me to be a HUGE task! I would be delighted to
be able to re-use my XUL knowledge, but still I am a bit worried that we
are taking on a huge task and might end up creating a hybrid that
neither takes advantage of the low-level qualities of Qx nor can deliver
on the promises of XUL. But I will be happy to be convinced by a
proof-of-concept.

Why don't we proceed like this: You implement a proof-of-concept parser
based on XUL, and I will, if time permits (I have a completely different
job) try to write a simple Serverside QxBuilder converter, based on the
client side code. In the final server product, these converters can be
plugged-in at will.

Christian







-------------------------------------------------------
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
Qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Claus Augusti]

Hi,

I've been following this discussion since the beginning now trying to
understand what's the point about using XUL for Qooxdoo. To me it seems
that Qooxdoo's widget and layout system is much more developed than XUL.
Also, you could only rebuild parts of the complete power of XUL as it's
only one player in a set of technologies. How would you handle Gecko's
proprietary (or soon to be standardized) CSS features without breaking
Qooxdoo's cross platform design? What about the templating system which
only makes sense with RDF datasources? You also would need to support
XBL to not cut out the X in XUL (EXtensible User Interface Language),
it's XBL that makes XUL easily extensible. With a "Qooxdoo-XUL" you
would also have to drop things like overlays, or at least parts of it,
since there wouldn't be a way to hook yourself up to the Browser's UI.
So, to summarize all this, I don't think using XUL as a interface
description language makes sense when you have to rip it out of it's
context (which makes it as unique as it is). However, I'd be interested
in spreading XUL more and would like to hear what you guys imagine.

Regards,
Claus


Oliver Vogel wrote:

>
>> I think the main value of using XUL is to borrow from a standard that
>> has
>> many UI-related challenges solved using standard patters as Ben
>> mentioned.
>> There are also a host of tools starting to spring up to edit XUL
>> definitions. Even visual drag and drop tools to design UI's.
>>  
>>
> only for my personal interrest - can you send me a link to a
> UI-deisgner creating XUL?
>
>> Using the QxBuilder syntax will work, but it may get pretty verbose
>> when you
>> start to link many components together with events.
>>
>> Do we have to have the XUL engine on the client side? It would be
>> ideal, but
>> it would further slow down loading of qooxdoo apps. Can we not
>> implement a
>> server component that will take the XUL definition and generate all
>> necessary javascript that qooxdoo will need and simply have qooxdoo
>> load it
>> into its context. I can write such a converter initially in PHP pretty
>> quickly.
>
> i think, this may be a good idea
>
>> There would be a client javascript component to it as well that
>> will call event callbacks with a context more comprehensive than qooxdoo
>> currently provides with its event system.
>>  
>>
> what is the problem of the event system used in qooxdoo?
>
>> This comes back to the question of how qooxdoo code should be defined to
>> maximize speed of loading. Is the API the fastest way or would it be
>> faster
>> to load some king of internal structure?
>>  
>>
> i think, we can use my class (maybe a rewritten class but like mine)
> and we should use the API (maybe i am wrong, but i think, this is
> easier to debug.
>
> Olli
>
>> Christoph
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/qooxdoo-PHP-framework-project-t1389226.html#a3768945 
>>
>> 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
>> Qooxdoo-devel@...
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>>  
>>
>
>
>
> -------------------------------------------------------
> 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
> Qooxdoo-devel@...
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>

--
 
Claus Augusti        
Pustefix Core / Pre-Production / Stuff

Telefon: [phone] - 172
1&1 Internet AG       Brauerstrasse 48  
http://www.1und1.de   76135 Karlsruhe

Q: Speaking of security, Internet Explorer has had well-publicized holes...
Gates: Understand those are cases where you are downloading third-party software.



-------------------------------------------------------
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
Qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Ulrich Schreiner]

hi,

one silly question: what's the problem which should be solved by this
"xul->qooxdoo" converter?

i fear you will end up in a converter which maps a subset of xul to a
subset of qooxdoo. so neither the xul guys are happy nor the qooxdoo
guys. it will be ok for simple form-based-apps, but i'm really in doubt
if you want to use QxTree, QxListView and much more of the complex
widgets (QxWindow, QxBarView, QxColorSelector, ...)

but back to my first question, i thought you want qooxdoo applications
to start quicker. hm, i don't see how a xml->qooxdoo converter which
runs on the serverside can help.

ok, you can try to load only those qooxdoo parts which are needed. but:
you have to "understand" the qooxdoo class hierarchy. well imho, the
easies and efficient way is to load "qooxdoo.js" (in its compressed form).

sorry, but i really don't see the advantage of a serverside component
which parses XML and produces (qooxdoo specific) JS.

sorry and thx

</usc>





Christian Boulanger wrote:

> ChristophDorn schrieb:
>>  I think the main value of using XUL is to borrow from a standard that
>> has
>> many UI-related challenges solved using standard patters as Ben
>> mentioned.
>> There are also a host of tools starting to spring up to edit XUL
>> definitions. Even visual drag and drop tools to design UI's.
>>  
> Ok, I agree on this. Being able to use GUI builders would be great.
>> Using the QxBuilder syntax will work, but it may get pretty verbose
>> when you
>> start to link many components together with events.
>>  
> But here comes the problem: with your XUL2QX parser, you need to map all
> the attributes of XUL to those of Qx and still after that, the
> javascript working with the widgets doesn't correspond to the XUL model.
> Isn't that a major drawback?
>> quickly. There would be a client javascript component to it as well that
>> will call event callbacks with a context more comprehensive than qooxdoo
>> currently provides with its event system.
>>  
> I assume this is where you would have to map all events, methods and
> properties. This seems to me to be a HUGE task! I would be delighted to
> be able to re-use my XUL knowledge, but still I am a bit worried that we
> are taking on a huge task and might end up creating a hybrid that
> neither takes advantage of the low-level qualities of Qx nor can deliver
> on the promises of XUL. But I will be happy to be convinced by a
> proof-of-concept.
>
> Why don't we proceed like this: You implement a proof-of-concept parser
> based on XUL, and I will, if time permits (I have a completely different
> job) try to write a simple Serverside QxBuilder converter, based on the
> client side code. In the final server product, these converters can be
> plugged-in at will.
>
> Christian
>
>
>
>
>
>
>
> -------------------------------------------------------
> 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
> Qooxdoo-devel@...
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

-------------------------------------------------------
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
Qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[panyasan]

Ulrich Schreiner schrieb:

> but back to my first question, i thought you want qooxdoo applications
> to start quicker. hm, i don't see how a xml->qooxdoo converter which
> runs on the serverside can help.
>
> ok, you can try to load only those qooxdoo parts which are needed.
> but: you have to "understand" the qooxdoo class hierarchy. well imho,
> the easies and efficient way is to load "qooxdoo.js" (in its
> compressed form).
>
> sorry, but i really don't see the advantage of a serverside component
> which parses XML and produces (qooxdoo specific) JS.

The advantage is that it looks nicer ... ;-)

No, but seriously, there is a huge advantage for using XML:
- you can avoid verbose, semantically redundant, and error-prone
javascript coding ("Verbose" seems to be my favorite word lately ;-) )
- you can deliver on-the-fly compressed javascript to the client of your
own code (not only of the qooxdoo core files)
- you can easily exchange GUI templates
- you could even, if you want, create converters from other GUI XML
description languages (such as XUL or Qt) or at least, rewrite those
with less hassle
- you can structure the XML to contain meta-information on the GUI
- you can use the same XML code even if the API changes - all you need
to update is the parser

As to speed: Server-side parsing is fast ennough to be not noticeable,
especially compared to the performance of QxBuilder. It has been one
idea of Sebastian early on, by the way!

Christian


-------------------------------------------------------
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
Qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Oliver Vogel-2]

> but back to my first question, i thought you want qooxdoo
> applications
> to start quicker. hm, i don't see how a xml->qooxdoo converter which
> runs on the serverside can help.
>
> ok, you can try to load only those qooxdoo parts which are
> needed. but:
> you have to "understand" the qooxdoo class hierarchy. well imho, the
> easies and efficient way is to load "qooxdoo.js" (in its
> compressed form).

 
I know, i repeat myself often (maybe to often) i am working heavilly on such
a thing, a php file which knows the dependencies and know how to handle with
it. With this script you only have to say " i need QxApplication, QxHtml,
QxLabel" -> doit() and my qooxdoo.php resolves the dependencies and creates
the smallest file available. Then this file is cached (for speed) and
compressed. The files are about 50% smaller then qooxdoo.js.gz!

The file is working in my environment but there are some missing
dependencies in the js-files. I am actually searching this missing
dependencies and send them all to sebastian. He applies this to the svn as
soon as he can (yes, this really works ;-). Aften i found most of then i
will release my file.

I someone likes to help me -> PLEASE TELL ME! I need a php script converted
from php to python (or something other which can be run under cygwin -> php
can't)

Olli



-------------------------------------------------------
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
Qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Ulrich Schreiner]

hi,

Christian Boulanger wrote:
> No, but seriously, there is a huge advantage for using XML:
> - you can avoid verbose, semantically redundant, and error-prone
> javascript coding ("Verbose" seems to be my favorite word lately ;-) )

well, i was involved in a xul project. as time goes by, the xml code
contained redundant parts, contained errors and so on. imho your points
are not specific to JS, they occur with any language or description
language.

if the xml is really descriptive it is an advantage. but this is an
ideal world i've never seen :-)

> - you can deliver on-the-fly compressed javascript to the client of your
> own code (not only of the qooxdoo core files)

hm, apache2 can do this too (filter), tomcat can do this (afaik with
filter), cherrypy (with filter). i guess php can do this too out of the box.

> - you can easily exchange GUI templates

in theory. did you ever try to "easily exchange templates" in a
HTML-webapp or a xul-app?

it's not fun and really not easy :-)

> - you could even, if you want, create converters from other GUI XML
> description languages (such as XUL or Qt) or at least, rewrite those
> with less hassle

sorry, but i don't believe :-). it is extremely hard to map different
gui frameworks. most of the time you have a small subset of all as a result.

> - you can structure the XML to contain meta-information on the GUI

correct, but that has nothing to do where this xml is parsed (server <->
client).

> - you can use the same XML code even if the API changes - all you need
> to update is the parser

well this depends on your xml grammatic. if this is completely decoupled
from qooxdoo you are right. but then your parser will be a complete new
product with new widgets and new properties. you cannot borrow the
propertynames from qooxdoo ... they can change.

nevertheless: now my application is coupled to your xml-DTD or schema
:-). and if this changes ...

i think this is one reason for xul, because this is standarized. but
imho it will be real real real hard to map xul to qooxdoo. imho it is
not possible.

> As to speed: Server-side parsing is fast ennough to be not noticeable,
> especially compared to the performance of QxBuilder. It has been one
> idea of Sebastian early on, by the way!

sure, serverside parsing is fast (if you don't have hundreds or
thousands of clients), but clientside parsing is not really slow :-).

in both cases qooxdoo objects have to be instanciated, properties have
to be set, and so one. one solution also has to parse xml on the client,
the other not.

but if you think serverside xml helps, no problem :-)

>
> Christian
>
>
> -------------------------------------------------------
> 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
> Qooxdoo-devel@...
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

-------------------------------------------------------
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
Qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Ulrich Schreiner]

hi,

well i don't doubt that this can be done. but my current application uses:
  - QxWindow (for login)
  - QxTree, QxMenu, QxToolbar, QxListView, QxTabView, QxIframe, many
widgets, many layouts, ...

now we are discussing using a QxBarView too.

i think i need about 80% of the qooxdoo-sourcefiles or more.

as i said: for formbased apps it is ok, and it can speed up things. but
what if you really need many parts of qooxdoo?

don't understand me wrong: if speed at startup is the issue, your
solution can be a way to solve. i only do not see an advantage of
parsing a xml file on the server and generate a qooxdoo-JS file :-)

thx
</usc>

Oliver Vogel wrote:

>> but back to my first question, i thought you want qooxdoo
>> applications
>> to start quicker. hm, i don't see how a xml->qooxdoo converter which
>> runs on the serverside can help.
>>
>> ok, you can try to load only those qooxdoo parts which are
>> needed. but:
>> you have to "understand" the qooxdoo class hierarchy. well imho, the
>> easies and efficient way is to load "qooxdoo.js" (in its
>> compressed form).
>  
> I know, i repeat myself often (maybe to often) i am working heavilly on such
> a thing, a php file which knows the dependencies and know how to handle with
> it. With this script you only have to say " i need QxApplication, QxHtml,
> QxLabel" -> doit() and my qooxdoo.php resolves the dependencies and creates
> the smallest file available. Then this file is cached (for speed) and
> compressed. The files are about 50% smaller then qooxdoo.js.gz!
>
> The file is working in my environment but there are some missing
> dependencies in the js-files. I am actually searching this missing
> dependencies and send them all to sebastian. He applies this to the svn as
> soon as he can (yes, this really works ;-). Aften i found most of then i
> will release my file.
>
> I someone likes to help me -> PLEASE TELL ME! I need a php script converted
> from php to python (or something other which can be run under cygwin -> php
> can't)
>
> Olli
>
>
>
> -------------------------------------------------------
> 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
> Qooxdoo-devel@...
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

-------------------------------------------------------
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
Qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[ChristophDorn]

You make some good points.

To be honest I did not really think about the consequences of having to implement the complete XUL standards.

I guess what I was most interested in was borrowing from XUL what we need and adding our own parts to complete the picture for qooxdoo. One main motivation for using XUL as the base was to possibly leverage existing or future development tools including visual designers and layout builders.

I will have to look at XUL in a lot more detail to be able to comment on this further.

Christoph

[ChristophDorn]

> nevertheless: now my application is coupled to your xml-DTD or schema
> :-). and if this changes ...

Schemas can be versiond, backwards compatible, the converter can be versioned. The XML can be designed with extensibility in mind. If it is an actively used schema there can be convertes to upgrade etc...


> i think this is one reason for xul, because this is standarized. but
> imho it will be real real real hard to map xul to qooxdoo. imho it is
> not possible.

Realistically we will likely end up borrowing some things from XUL rather than completely map it.


> but if you think serverside xml helps, no problem :-)

For me it does not matter if the XML is parsed server side or client side. As long as loading it into qooxdoo will not slow down application loading/rendering.
My motivation for using XML is to generate UI components based on existing meta information I can draw out of my applications. This way I can auto-generate for example form field definitions including validation rules and only need to implemenet the business logic to save the data once it gets back to the server. Sure I can generate javascript out of the meta information but I think XML provides a much cleaner option.

Christoph

[Oliver Vogel-2]

Mabye it was better for me, not to say anyting because i made a fool out of
me, but what i can't understand is:
If you create xml and send this to the client - how do you think, you can
debug this?
With javaScript - debugging is no problem, because every javascript debugger
can handle it.

Maybe it is a totally foolish question, but why not creating a "offline" -
compiler. You create you app with XML (or xul in special) and "compile" this
into a true javascript - file. This file is then stored at the server and
send to the client (maybe compressed). To parse Javascript is faster than to
parse XML and it is absolutelly easy to debug?

Olli


==================================================
Diplom-Informatiker
Oliver Vogel
Geschaeftsfuehrer

Meins und Vogel GmbH  E-Mail: O.Vogel@...
Esslinger Str. 45     Tel.:   [phone]
                      Fax:    [phone]
D 73207 Plochingen    http://www.muv.com/

Handelsregister: Esslingen am Neckar HRB 3536
Geschäftsführer: Dipl.-Inf. Klaus  Meins
                 Dipl.-Inf. Oliver Vogel
==================================================
"wer Rechtschreibfehler findet darf sie behalten"

> -----Ursprüngliche Nachricht-----
> Von: qooxdoo-devel-admin@...
> [mailto:qooxdoo-devel-admin@...] Im Auftrag
> von ChristophDorn
> Gesendet: Donnerstag, 6. April 2006 18:23
> An: qooxdoo-devel@...
> Betreff: Re: [qooxdoo-devel] qooxdoo / PHP framework project
>
>
> > nevertheless: now my application is coupled to your xml-DTD
> or schema
> > :-). and if this changes ...
>
> Schemas can be versiond, backwards compatible, the converter can be
> versioned. The XML can be designed with extensibility in
> mind. If it is an
> actively used schema there can be convertes to upgrade etc...
>
>
> > i think this is one reason for xul, because this is
> standarized. but
> > imho it will be real real real hard to map xul to qooxdoo.
> imho it is
> > not possible.
>
> Realistically we will likely end up borrowing some things
> from XUL rather
> than completely map it.
>
>
> > but if you think serverside xml helps, no problem :-)
>
> For me it does not matter if the XML is parsed server side or
> client side.
> As long as loading it into qooxdoo will not slow down application
> loading/rendering.
> My motivation for using XML is to generate UI components
> based on existing
> meta information I can draw out of my applications. This way I can
> auto-generate for example form field definitions including
> validation rules
> and only need to implemenet the business logic to save the
> data once it gets
> back to the server. Sure I can generate javascript out of the meta
> information but I think XML provides a much cleaner option.
>
> Christoph
> --
> View this message in context:
> http://www.nabble.com/qooxdoo-PHP-framework-project-t1389226.h

tml#a3787898

> 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
> Qooxdoo-devel@...
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>



-------------------------------------------------------
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&kid0944&bid$1720&dat1642
_______________________________________________
Qooxdoo-devel mailing list
Qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[panyasan]

> Mabye it was better for me, not to say anyting because i made a fool out
> of
> me, but what i can't understand is:
> If you create xml and send this to the client - how do you think, you can
> debug this?
> With javaScript - debugging is no problem, because every javascript
> debugger
> can handle it.
>
> Maybe it is a totally foolish question, but why not creating a "offline" -
> compiler. You create you app with XML (or xul in special) and "compile"
> this
> into a true javascript - file. This file is then stored at the server and
> send to the client (maybe compressed). To parse Javascript is faster than
> to
> parse XML and it is absolutelly easy to debug?
>
> Olli

The point, at least for me, is that the XML structure is such that the
generated javascript should be error-free, because the parser will only
accept xml which "makes sense", and won't make any typos. if, for example,
I have

<qx:atom text="this is a label" icon="icons/16/history.png" left="0"
top="0"/>

the generated javascript will be something like

var tmp_001=new QxAtom();tmp_001.setText("this is a
label");tmp_001.setIcon("icons/16/history.png");tmp_001.setLeft(0);tmp_001.setTop(0);cldoc.add(tmp_001);

(note that I am still working with Qx v0.1)

While in the javascript, you can have a typo which you need to debug, in
the xml you (at least ideally) cannot, since it has to be valid xml and
could even be validated for correct properties and nesting (at least in an
ideal world).

what still needs to be debugged are <qx:script> sections, this might be a
problem when compressing the code.

My test case to compare QxBuilder and a server-side solution is a huge
widget with 5 tabs, 10 Textareas and 30 -40 textfields. With QxBuilder, it
takes 10 or more seconds to build the widget and I get a script timeout
warning unless I insert some setTimeouts. I hope that pure javascript will
be a bit faster - but to be honest, I don't know. I have so far simply
assumed that this would be the case.

Christian



-------------------------------------------------------
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
Qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Oliver Vogel-2]

> what still needs to be debugged are <qx:script> sections,
> this might be a
> problem when compressing the code.
That's exactelly what i mean, the GUI is IMHO no problem but a "normal" app
has not only gui, it has some kind of functions!
And how to debug them inside XML (how to set a breakpoint for example - in
pure JavaScript this is no problem but INSIDE XML???)

>
> My test case to compare QxBuilder and a server-side solution is a huge
> widget with 5 tabs, 10 Textareas and 30 -40 textfields. With
> QxBuilder, it
> takes 10 or more seconds to build the widget and I get a
> script timeout
> warning unless I insert some setTimeouts. I hope that pure
> javascript will
> be a bit faster - but to be honest, I don't know. I have so far simply
> assumed that this would be the case.

I think, javascript is even faster (many times faster) than parsing XML

So i think, it is better to make a "offline" compiler -> just write the
(error-free) XML and generate a javascript-script.
The GUI is then ready (and error free and easier to make than writing code
by your own) and than you can beginn to fill the functionality (and if this
is ok copy it back to the XML - if you like) so that you can do the
generation more than once)

Olli



-------------------------------------------------------
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
Qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Jason Priebe]

> Oliver Vogel wrote:
>
> > what still needs to be debugged are <qx:script> sections,
> this might
> > be a problem when compressing the code.

> That's exactelly what i mean, the GUI is IMHO no problem but
> a "normal" app has not only gui, it has some kind of functions!
> And how to debug them inside XML (how to set a breakpoint for
> example - in pure JavaScript this is no problem but INSIDE XML???)

I agree with Olli.  I started down the road of a PHP framework that
would have classes corresponding to the QX classes.  You could assemble
a UI in PHP, then ask it to dump the Javascript.  I gave up after a
week or two.

I now treat my client-side code as a standalone client application
that uses Sajax to communicate with the server.  This model is a lot
easier for me to work with.

Here are the two biggest problems I had with trying to generate the
Javascript in server-side PHP:

  - specifying event handlers is horrible -- you have to include big
    blocks of Javascript code in your PHP (or in the proposed system,
    in the XML).  Coding Javascript is tough enough with the current
    tools, and doing it inside of another language's development
    environment doesn't make it easier.  The bulk of my application's
    code is event handlers, Sajax calls, and callbacks.

  - managing variable names of the widgets is pretty awful, too --
    your events will presumably want to modify or add data to the
    widgets -- how will they refer to the widgets?

  - you can't make a layout property of a QX widget dependent on a
    layout property of another widget, because the actual Javascript
    QX widgets (and their layout behaviors) don't really exist yet.

I don't think that these issues are insurmountable -- I just think you
should give a lot of consideration to them before investing too much
time.

Good luck!

Jason Priebe
CBC New Media

> -----Original Message-----
> From: qooxdoo-devel-admin@...
> [mailto:qooxdoo-devel-admin@...] On Behalf
>
>
> >
> > My test case to compare QxBuilder and a server-side
> solution is a huge
> > widget with 5 tabs, 10 Textareas and 30 -40 textfields. With
> > QxBuilder, it takes 10 or more seconds to build the widget
> and I get a
> > script timeout warning unless I insert some setTimeouts. I
> hope that
> > pure javascript will be a bit faster - but to be honest, I
> don't know.
> > I have so far simply assumed that this would be the case.
>
> I think, javascript is even faster (many times faster) than
> parsing XML
>
> So i think, it is better to make a "offline" compiler -> just
> write the
> (error-free) XML and generate a javascript-script.
> The GUI is then ready (and error free and easier to make than
> writing code by your own) and than you can beginn to fill the
> functionality (and if this is ok copy it back to the XML - if
> you like) so that you can do the generation more than once)
>
> Olli
>
>
>
> -------------------------------------------------------
> 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
> Qooxdoo-devel@...
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>

-------------------------------------------------------
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&kid0944&bid$1720&dat1642
_______________________________________________
Qooxdoo-devel mailing list
Qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[panyasan]

Hello Jason,

I guess we (the proponents of an XML server-side solution) should be
writing code instead of talking, but maybe just a few points, the main
being that using QxBuilder has been great so far and did not pose any of
the problems you are talking about except that it was... SLOW. If indeed
I should find out that client-side XML parsing is not the problem, I
will not invest so much time into server-side parsing. I am NOT talking
about javascript generation by PHP, which I find very unappealing

Priebe, Jason schrieb:
>   - specifying event handlers is horrible -- you have to include big
>     blocks of Javascript code in your PHP (or in the proposed system,
>     in the XML).  Coding Javascript is tough enough with the current
>     tools, and doing it inside of another language's development
>     environment doesn't make it easier.  The bulk of my application's
>     code is event handlers, Sajax calls, and callbacks.
>  
Have a look at the QxBuilder solution: very elegant and simple:
        <qx:textField
            id="bg_search_replace_search_text"
            top="30" left="150" width="250">
            <qx:eventListener type='input' >
                bg.getWidget("detailview").matchEntry ( event.getTarget(),
                   
 bg_search_replace_dropdown_search.getList().getSelectedItem().getValue(),
                     event.getNewValue() );
            </qx:eventListener>
        </qx:textField>

( I attach the whole widget)
>   - managing variable names of the widgets is pretty awful, too --
>     your events will presumably want to modify or add data to the
>     widgets -- how will they refer to the widgets?
>  
well, each widget has a unique id. Where is the problem? ;-)
>   - you can't make a layout property of a QX widget dependent on a
>     layout property of another widget, because the actual Javascript
>     QX widgets (and their layout behaviors) don't really exist yet.
>
>  
I would think that using creation events solves this problem. You can
always redraw widgets when a layout property of another widget changes,
since the ingenious event system of Qx monitors all changes.
> I don't think that these issues are insurmountable -- I just think you
> should give a lot of consideration to them before investing too much
> time.
>  
As I said, the mere existence and usefulness of QxBuilder has shown that
these issues don't really pose a problem. All I want is to move the
parsing to the server and extend the idea of QxBuilder to use XML not
only to describe single widgets, but a whole application.

Christian

<?xml version="1.0" encoding="utf-8"?>
<qx:widgets xmlns:qx="http://qooxdoo.sourceforge.net">


        <tal:block define="config this/getConfig;
                                                         fields php: config.getKeys('field_definition.fields')"/>
                                                         
        <qx:window  id="bg_search_replace"
                left="100" top="100"
                width="410" height="130"
                allowMinimize="false" showMinimize="false"
                tal:attributes="caption php: __('Search and Replace')">
               
                <qx:atom top="5" left="5"
                        tal:attributes="text php: __('Field to search in') "/>

                <qx:comboBox
            id="bg_search_replace_dropdown_search"
            top="5" left="150"  right="5" width="250">
                        <qx:listItem tal:repeat="field fields"
                                tal:attributes="value field; text php:__( field ) "/>
                        <qx:eventListener type='changeSelected' >
                                bg_search_replace_search_text.setText("");
                                bg_search_replace_replace_text.setText("");
                        </qx:eventListener>  
                </qx:comboBox>
               
                <qx:atom top="30" left="5"
                        tal:attributes="text php: __('Text to search for') "/>

                <qx:textField
                        id="bg_search_replace_search_text"
                        top="30" left="150" width="250">
                        <qx:eventListener type='input' >
                                bg.getWidget("detailview").matchEntry ( event.getTarget(),
                                         bg_search_replace_dropdown_search.getList().getSelectedItem().getValue(),
                                         event.getNewValue() );
                        </qx:eventListener>  
                </qx:textField>
               
                <qx:atom top="55" left="5"
                        tal:attributes="text php: __('Text to replace with') "/>

                <qx:textField
                        id="bg_search_replace_replace_text"
                        top="55" left="150" width="250">
                        <qx:eventListener type='input' >
                                bg.getWidget("detailview").matchEntry ( event.getTarget(),
                                         bg_search_replace_dropdown_search.getList().getSelectedItem().getValue(),
                                         event.getNewValue() );
                        </qx:eventListener>  
                </qx:textField>

        <qx:atom
            bottom="0" left="5" height="22"
            tal:attributes="text php: __('Leave search text empty to replace the whole field.')"/>

        <qx:button
            bottom="0" right="5" height="22" width="60"
                        id="bg_search_replace_submit_button"
            icon="icons/16/ok.png"
            iconPosition="left"
            text="Send">
                        <qx:eventListener type='click' >
                                bg_search_replace.execute();
                        </qx:eventListener>  
                        <qx:eventListener type="canEditFolderContents">
                                this.setEnabled ( event.getNewValue() );
                        </qx:eventListener>
                </qx:button>
               
                <qx:script>

                        bg.listview.getIds = function (){return this.data.ids;}
                       
                        bg_search_replace.open();
                       
                       
                        bg_search_replace.execute = function () {
                                var sItem = bg_search_replace_dropdown_search.getList().getSelectedItem();
                                if ( ! sItem ) return;
                               
                                var field = bg_search_replace_dropdown_search.getList().getSelectedItem().getValue();
                                var search = ( bg_search_replace_search_text.getText() );
                                var replace = ( bg_search_replace_replace_text.getText() );
                                var referenceIds = bg.listview.getIds();
                               
                                if ( ! referenceIds.length ) {
                                        alert ( _("No references to operate on.") );
                                        return;
                                }
                               
                                if ( ! search && ! replace ) {
                                        alert ( _("Please provide values either for search or replace." ) );
                                        return;
                                }
                               
                                if ( ! search ) search="";
                                if ( ! replace ) replace="";
                               
                                var confirmMsg = "Are you sure you want to " +
                                                                 ( search ?  
                                                                        ( "replace '" + search + "' by '" + replace + "' in " + "field " + _( field ) ) :
                                                                        ( "overwrite field " + _( field ) + " with '" + replace + "'" )
                                                                 )  + "?";
                               
                                if ( ! confirm ( confirmMsg ) ) return;
                                var _alert = bg.alert ( _("Please wait"),false, "history" );
                                dojo.io.bind({
                                        url: bg.url + "/data/search_replace",
                                        content : { datasource   : bg.listview.datasource,
                                                                referenceIds : referenceIds.join(","),
                                                                field        : field,
                                                                search       : search,
                                                                replace : replace },    
                                        method : "post",                            
                                        handler: function(type, response, evt){
                                                                bg.endRequest();
                                                                _alert.setVisible(false);
                                                                try {
                                                                        data = eval(response);
                                                                } catch (e) {
                                                                        alert ( response );
                                                                        return false;
                                                                }
                                                                bg.listview.reload();
                                                                bg.detailview.reload();
                                                                //alert ( data.number + " references updated." );
                                                        },
                                        mimetype: "text/plain"
                                });
                        }
                </qx:script>
    </qx:window>
</qx:widgets>

[Sebastian Werner]

Hi All!

I just want to throw something inside this thread. Completely unspecific
to this current message ;)

Have you all thought about to just contribute to one of the newly
upcoming "Rapid Development Frameworks" instead of creating a new one.

For PHP:
http://phpontrax.com/
http://cakephp.org/
http://www.symfony-project.com/

For Python:
http://www.djangoproject.com/

For Ruby, sure:
http://rubyonrails.org/

I think these frameworks could be really well used (after some work) to
build qooxdoo applications. In my opinion it's more than just create a
interface.

Also I think to have a xml markup to describe the interface is a good
idea. That's really great I think. There are different possibilities to
implement this:

1. Send the XML to the Client and let QxBuilder transform the XML to
JS-Code (maybe to slow)
2. Send the XML to the Client and let XSLT (client locally) transform
the XML to JS-Code (should be faster than option one)
3. Convert the XML at server side to JS-Code. Using XSLT or some other
language. (This results in my opinion to big JS-Code you must transfer
to the client.)
4. Convert the XML at server side to JSON. Using a new qooxdoo class to
transform this JSON code to JavaScript objects. (In my opinion the best
choice. The code which needs to be send to the client in relatively
small and also it's possible for the client to render this stuff really
quickly.)

Just my 2 cents.

Sebastian



Priebe, Jason schrieb:

>> Oliver Vogel wrote:
>>
>>> what still needs to be debugged are <qx:script> sections,
>> this might
>>> be a problem when compressing the code.
>
>> That's exactelly what i mean, the GUI is IMHO no problem but
>> a "normal" app has not only gui, it has some kind of functions!
>> And how to debug them inside XML (how to set a breakpoint for
>> example - in pure JavaScript this is no problem but INSIDE XML???)
>
> I agree with Olli.  I started down the road of a PHP framework that
> would have classes corresponding to the QX classes.  You could assemble
> a UI in PHP, then ask it to dump the Javascript.  I gave up after a
> week or two.
>
> I now treat my client-side code as a standalone client application
> that uses Sajax to communicate with the server.  This model is a lot
> easier for me to work with.
>
> Here are the two biggest problems I had with trying to generate the
> Javascript in server-side PHP:
>
>   - specifying event handlers is horrible -- you have to include big
>     blocks of Javascript code in your PHP (or in the proposed system,
>     in the XML).  Coding Javascript is tough enough with the current
>     tools, and doing it inside of another language's development
>     environment doesn't make it easier.  The bulk of my application's
>     code is event handlers, Sajax calls, and callbacks.
>
>   - managing variable names of the widgets is pretty awful, too --
>     your events will presumably want to modify or add data to the
>     widgets -- how will they refer to the widgets?
>
>   - you can't make a layout property of a QX widget dependent on a
>     layout property of another widget, because the actual Javascript
>     QX widgets (and their layout behaviors) don't really exist yet.
>
> I don't think that these issues are insurmountable -- I just think you
> should give a lot of consideration to them before investing too much
> time.
>
> Good luck!
>
> Jason Priebe
> CBC New Media
>
>> -----Original Message-----
>> From: qooxdoo-devel-admin@...
>> [mailto:qooxdoo-devel-admin@...] On Behalf
>>
>>
>>> My test case to compare QxBuilder and a server-side
>> solution is a huge
>>> widget with 5 tabs, 10 Textareas and 30 -40 textfields. With
>>> QxBuilder, it takes 10 or more seconds to build the widget
>> and I get a
>>> script timeout warning unless I insert some setTimeouts. I
>> hope that
>>> pure javascript will be a bit faster - but to be honest, I
>> don't know.
>>> I have so far simply assumed that this would be the case.
>> I think, javascript is even faster (many times faster) than
>> parsing XML
>>
>> So i think, it is better to make a "offline" compiler -> just
>> write the
>> (error-free) XML and generate a javascript-script.
>> The GUI is then ready (and error free and easier to make than
>> writing code by your own) and than you can beginn to fill the
>> functionality (and if this is ok copy it back to the XML - if
>> you like) so that you can do the generation more than once)
>>
>> Olli
>>
>>
>>
>> -------------------------------------------------------
>> 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
>> Qooxdoo-devel@...
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>>
>
>
> -------------------------------------------------------
> 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=k&kid0944&bid$1720&dat1642
> _______________________________________________
> Qooxdoo-devel mailing list
> Qooxdoo-devel@...
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

-------------------------------------------------------
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
Qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[panyasan]

Yeah!

Sebastian Werner schrieb:

> Hi All!
>
> I just want to throw something inside this thread. Completely
> unspecific to this current message ;)
>
> Have you all thought about to just contribute to one of the newly
> upcoming "Rapid Development Frameworks" instead of creating a new one.
>
> For PHP:
> http://phpontrax.com/
> http://cakephp.org/
> http://www.symfony-project.com/
>

Actually, I have never heard of them before (my fault). We should hav a
look!
> 4. Convert the XML at server side to JSON. Using a new qooxdoo class
> to transform this JSON code to JavaScript objects. (In my opinion the
> best choice. The code which needs to be send to the client in
> relatively small and also it's possible for the client to render this
> stuff really quickly.)
Thas is a great idea!!! I am in favour of that, too! Would it be a big
hassle to write this class? Sebastian, would you consider donating some
of your precious time to at least write a codebase that we can further
work with, if we take care of the server-side implementations? You (or
the other developers) are just the closest to the design of qooxdoo to
make this really efficient and fast.

Christian


-------------------------------------------------------
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
Qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Ulrich Schreiner]

For Python:
http://www.turbogears.com, JSON included, very similair to django

in the latest version (only alpha) a nice ajax model designer is included:

http://www.checkandshare.com/modelDesigner/

derived from the cool ajax sql designer:

http://ondras.praha12.net/sql/demo/

perhaps someone is smart enough to do a qooxdoo designer with qooxdoo :-)

Sebastian Werner wrote:

> Hi All!
>
> I just want to throw something inside this thread. Completely unspecific
> to this current message ;)
>
> Have you all thought about to just contribute to one of the newly
> upcoming "Rapid Development Frameworks" instead of creating a new one.
>
> For PHP:
> http://phpontrax.com/
> http://cakephp.org/
> http://www.symfony-project.com/
>
> For Python:
> http://www.djangoproject.com/
>
> For Ruby, sure:
> http://rubyonrails.org/
>
> I think these frameworks could be really well used (after some work) to
> build qooxdoo applications. In my opinion it's more than just create a
> interface.
>
> Also I think to have a xml markup to describe the interface is a good
> idea. That's really great I think. There are different possibilities to
> implement this:
>
> 1. Send the XML to the Client and let QxBuilder transform the XML to
> JS-Code (maybe to slow)
> 2. Send the XML to the Client and let XSLT (client locally) transform
> the XML to JS-Code (should be faster than option one)
> 3. Convert the XML at server side to JS-Code. Using XSLT or some other
> language. (This results in my opinion to big JS-Code you must transfer
> to the client.)
> 4. Convert the XML at server side to JSON. Using a new qooxdoo class to
> transform this JSON code to JavaScript objects. (In my opinion the best
> choice. The code which needs to be send to the client in relatively
> small and also it's possible for the client to render this stuff really
> quickly.)
>
> Just my 2 cents.
>
> Sebastian
>
>
>
> Priebe, Jason schrieb:
>>> Oliver Vogel wrote:
>>>
>>>> what still needs to be debugged are <qx:script> sections,
>>> this might
>>>> be a problem when compressing the code.
>>
>>> That's exactelly what i mean, the GUI is IMHO no problem but a
>>> "normal" app has not only gui, it has some kind of functions!
>>> And how to debug them inside XML (how to set a breakpoint for example
>>> - in pure JavaScript this is no problem but INSIDE XML???)
>>
>> I agree with Olli.  I started down the road of a PHP framework that
>> would have classes corresponding to the QX classes.  You could assemble
>> a UI in PHP, then ask it to dump the Javascript.  I gave up after a
>> week or two.
>>
>> I now treat my client-side code as a standalone client application
>> that uses Sajax to communicate with the server.  This model is a lot
>> easier for me to work with.
>>
>> Here are the two biggest problems I had with trying to generate the
>> Javascript in server-side PHP:
>>
>>   - specifying event handlers is horrible -- you have to include big
>>     blocks of Javascript code in your PHP (or in the proposed system,
>>     in the XML).  Coding Javascript is tough enough with the current
>>     tools, and doing it inside of another language's development
>>     environment doesn't make it easier.  The bulk of my application's
>>     code is event handlers, Sajax calls, and callbacks.
>>
>>   - managing variable names of the widgets is pretty awful, too --
>>     your events will presumably want to modify or add data to the
>>     widgets -- how will they refer to the widgets?
>>
>>   - you can't make a layout property of a QX widget dependent on a
>>     layout property of another widget, because the actual Javascript
>>     QX widgets (and their layout behaviors) don't really exist yet.
>> I don't think that these issues are insurmountable -- I just think you
>> should give a lot of consideration to them before investing too much
>> time.
>>
>> Good luck!
>>
>> Jason Priebe
>> CBC New Media
>>> -----Original Message-----
>>> From: qooxdoo-devel-admin@...
>>> [mailto:qooxdoo-devel-admin@...] On Behalf
>>>
>>>> My test case to compare QxBuilder and a server-side
>>> solution is a huge
>>>> widget with 5 tabs, 10 Textareas and 30 -40 textfields. With
>>>> QxBuilder, it takes 10 or more seconds to build the widget
>>> and I get a
>>>> script timeout warning unless I insert some setTimeouts. I
>>> hope that
>>>> pure javascript will be a bit faster - but to be honest, I
>>> don't know.
>>>> I have so far simply assumed that this would be the case.
>>> I think, javascript is even faster (many times faster) than parsing XML
>>>
>>> So i think, it is better to make a "offline" compiler -> just write the
>>> (error-free) XML and generate a javascript-script.
>>> The GUI is then ready (and error free and easier to make than writing
>>> code by your own) and than you can beginn to fill the functionality
>>> (and if this is ok copy it back to the XML - if you like) so that you
>>> can do the generation more than once)
>>>
>>> Olli
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> 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
>>> Qooxdoo-devel@...
>>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>>>
>>
>>
>> -------------------------------------------------------
>> 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=k&kid0944&bid$1720&dat1642
>> _______________________________________________
>> Qooxdoo-devel mailing list
>> Qooxdoo-devel@...
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
>
> -------------------------------------------------------
> 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
> Qooxdoo-devel@...
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

-------------------------------------------------------
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
Qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel