qooxdoo / PHP framework project

[ChristophDorn]

I am interested in leading a qooxdoo / PHP framework project. I am not sure what the best way to go about this is.

 

One option is to have it as a sub-project of qooxdoo with its own SVN repository and mailing list. The other option is to register it as a new separate project.

 

I am leaning towards registering it as a separate project so it can operate independently but it will be important to have as many interested qooxdoo users who use PHP also registered with the project mailing list.

 

We also need a name for the project. Not sure if it should implicate qooxdoo in the name or if it should be more generic and qooxdoo is its first and major supported framework?

 

Some ideas:

 

qooxdoophp

phpjsui (php javascript user interface)

phpju (php javascript UI)

phpjsclient (php javascript client) or "pjc"

 

Christoph

[Oliver Vogel-2]

1) qooxdoo-php

2)i think a new separate project is even better, because then you are
independend and can "make your own things" - but both projects should
"link together"

Olli





Christoph Dorn schrieb:

> I am interested in leading a qooxdoo / PHP framework project. I am not
> sure what the best way to go about this is.
>  
> One option is to have it as a sub-project of qooxdoo with its own SVN
> repository and mailing list. The other option is to register it as a
> new separate project.
>  
> I am leaning towards registering it as a separate project so it can
> operate independently but it will be important to have as many
> interested qooxdoo users who use PHP also registered with the project
> mailing list.
>  
> We also need a name for the project. Not sure if it should implicate
> qooxdoo in the name or if it should be more generic and qooxdoo is its
> first and major supported framework?
>  
> Some ideas:
>  
> qooxdoophp
> phpjsui (php javascript user interface)
> phpju (php javascript UI)
> phpjsclient (php javascript client) or "pjc"
>  
> Christoph

-------------------------------------------------------
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

[Ben Alex-5]

Christoph Dorn wrote:
> I am interested in leading a qooxdoo / PHP framework project. I am not
> sure what the best way to go about this is.
>
Hi Christoph

I have read the remainder of this thread, and as far as I can see the
proposed framework is XML-based. Is this correct? What PHP-centric parts
would there be?

I think it would be valuable if there was a high-level architectural
diagram showing the layering you had in mind for this project, such as
where XML is generated, parsed, data exchanged, JavaScript written, and
language-specific callbacks used. This would allow further discussion
not only about the technical approach, but also which projects (Qooxdoo,
PHP-Qooxdoo, Java-Qooxdoo etc) should develop which layers and modules
within those layers. I'd ideally like to see server-side language usage
minimised and kept as a very thin stub over the XML with perhaps
communication over an agreed protocol (I'm a big fan of JSON-RPC as
mentioned on this list in the past). If the community can agree on the
best technical architecture and layering for Qooxdoo-specific
server-side interoperability, I am happy to assist with a Java port of
the server-side code.

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

[Kent Olsson]

Hi!

> I am interested in leading a qooxdoo / PHP framework project. I am not
> sure what the best way to go about this is.
>  
> One option is to have it as a sub-project of qooxdoo with its own SVN
> repository and mailing list. The other option is to register it as a
> new separate project.

I vote for a new separate project, cause it has a wider framework than
qooxdoo.
 

> I am leaning towards registering it as a separate project so it can
> operate independently but it will be important to have as many
> interested qooxdoo users who use PHP also registered with the project
> mailing list.
>  
> We also need a name for the project. Not sure if it should implicate
> qooxdoo in the name or if it should be more generic and qooxdoo is its
> first and major supported framework?
>  
> Some ideas:
>  
> qooxdoophp

not wise if you want to do something else with other libraries in future

> phpjsui (php javascript user interface)
no
> phpju (php javascript UI)
no
> phpjsclient (php javascript client) or "pjc"
well

maybe....
php-backbone

Kent

> Christoph



-------------------------------------------------------
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]

It may be a good idea to split this into two projects.
One would focus on developing an XML schema to describe a qooxdoo
application and converters to generate the javascript code. The converters
should support multiple languages (php, java) and possibly even XSL.

My main interest is on the php server side aspect to provide tools for
developers to generate this XML definition easily and to provide a framework
that can also hold business logic written in PHP.

I would definetely participate in the definition of the XML schema and the
converters (especially the PHP one) but I am not sure if I am the best
person to head this project as I dont have the in-depth knowledge of qooxdoo
where it is headed and how the XML schema should be structured to stay
flexible. I am hoping that by using XML and converters to generate
javascript that we can bi-pass the verbose qooxdoo api and directly define
objects in their internal and private structures. I am hoping that this
would speed up loading times.

In addition we need a way to load sub-components of an application on demand
and have the client add the definitions to an already loaded application
(like flash does it with include files) so we dont have to load the entire
app at once. Ideally there would be a way to un-load components as well and
reload them so that they can be debugged without having to re-load the
entire qooxdoo app and navigate to the same context again.

So have two projects?
"qooxdoo-xml" and "php-qooxdoo,java-qooxdoo"

Christoph

 

-----Original Message-----
From: qooxdoo-devel-admin@...
[mailto:qooxdoo-devel-admin@...] On Behalf Of Ben Alex
Sent: Monday, April 03, 2006 3:19 PM
To: qooxdoo-devel@...
Subject: Re: [qooxdoo-devel] qooxdoo / PHP framework project

Christoph Dorn wrote:
> I am interested in leading a qooxdoo / PHP framework project. I am not
> sure what the best way to go about this is.
>
Hi Christoph

I have read the remainder of this thread, and as far as I can see the
proposed framework is XML-based. Is this correct? What PHP-centric parts
would there be?

I think it would be valuable if there was a high-level architectural diagram
showing the layering you had in mind for this project, such as where XML is
generated, parsed, data exchanged, JavaScript written, and language-specific
callbacks used. This would allow further discussion not only about the
technical approach, but also which projects (Qooxdoo, PHP-Qooxdoo,
Java-Qooxdoo etc) should develop which layers and modules within those
layers. I'd ideally like to see server-side language usage minimised and
kept as a very thin stub over the XML with perhaps communication over an
agreed protocol (I'm a big fan of JSON-RPC as mentioned on this list in the
past). If the community can agree on the best technical architecture and
layering for Qooxdoo-specific server-side interoperability, I am happy to
assist with a Java port of the server-side code.

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



-------------------------------------------------------
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]

> maybe....
> php-backbone

I think that is too generic and sets too high of an expectation.

It looks like there will be several projects covering different aspects of the proposed framework. Maybe we should wait with names until we have an exact idea what each project will do. Unless you think of a really cool name that does not really specifiy any technology :)

Christoph

[Benjamin Reitzammer-5]

Hi,

Ben Alex wrote:

> I think it would be valuable if there was a high-level architectural
> diagram showing the layering you had in mind for this project, such as
> where XML is generated, parsed, data exchanged, JavaScript written, and
> language-specific callbacks used. This would allow further discussion
> not only about the technical approach, but also which projects (Qooxdoo,
> PHP-Qooxdoo, Java-Qooxdoo etc) should develop which layers and modules
> within those layers. I'd ideally like to see server-side language usage
> minimised and kept as a very thin stub over the XML with perhaps
> communication over an agreed protocol (I'm a big fan of JSON-RPC as
> mentioned on this list in the past).  [...]

I agree with Ben here. I think it would be very useful, if a project
would define some kind of meta-framework or API, that could be
implemented by any language. Such a project would probably even attract
more developers from the start, because it's not limited to a specific
implementation. :)

The hard work is in the definition process anyway, so why not make it
platform/language-independent.

Such a project would have me as a hard-thinking mailing-list-subscriber
in the least.

Regarding project-structure/name:
IMHO it would be best, if there was one project called maybe
qooxdoo-server or qx-serverside (or qooxdoo-global becuase this could
span the whole "globe" of applications, where qooxdoo can be involved?).
This project should define a framework/API for the serverside, and the
communication layer (a level higher than qooxdoo's own, with dynamic
code loading and things like that).

Sub-projects within qooxdoo-global then would be the
language-implementations of the framework.

Cheers

Benjamin



-------------------------------------------------------
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

[Sebastian Werner]

Benjamin Reitzammer schrieb:

> Hi,
>
> Ben Alex wrote:
>> I think it would be valuable if there was a high-level architectural
>> diagram showing the layering you had in mind for this project, such as
>> where XML is generated, parsed, data exchanged, JavaScript written,
>> and language-specific callbacks used. This would allow further
>> discussion not only about the technical approach, but also which
>> projects (Qooxdoo, PHP-Qooxdoo, Java-Qooxdoo etc) should develop which
>> layers and modules within those layers. I'd ideally like to see
>> server-side language usage minimised and kept as a very thin stub over
>> the XML with perhaps communication over an agreed protocol (I'm a big
>> fan of JSON-RPC as mentioned on this list in the past).  [...]
>
> I agree with Ben here. I think it would be very useful, if a project
> would define some kind of meta-framework or API, that could be
> implemented by any language. Such a project would probably even attract
> more developers from the start, because it's not limited to a specific
> implementation. :)
>
> The hard work is in the definition process anyway, so why not make it
> platform/language-independent.
>
> Such a project would have me as a hard-thinking mailing-list-subscriber
> in the least.
>
> Regarding project-structure/name:
> IMHO it would be best, if there was one project called maybe
> qooxdoo-server or qx-serverside (or qooxdoo-global becuase this could
> span the whole "globe" of applications, where qooxdoo can be involved?).
> This project should define a framework/API for the serverside, and the
> communication layer (a level higher than qooxdoo's own, with dynamic
> code loading and things like that).
>
> Sub-projects within qooxdoo-global then would be the
> language-implementations of the framework.

This sounds great.

Sebastian

>
> Cheers
>
> Benjamin
>
>
>
> -------------------------------------------------------
> 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]

Ben Alex schrieb:

> I think it would be valuable if there was a high-level architectural
> diagram showing the layering you had in mind for this project, such as
> where XML is generated, parsed, data exchanged, JavaScript written,
> and language-specific callbacks used. This would allow further
> discussion not only about the technical approach, but also which
> projects (Qooxdoo, PHP-Qooxdoo, Java-Qooxdoo etc) should develop which
> layers and modules within those layers. I'd ideally like to see
> server-side language usage minimised and kept as a very thin stub over
> the XML with perhaps communication over an agreed protocol (I'm a big
> fan of JSON-RPC as mentioned on this list in the past). If the
> community can agree on the best technical architecture and layering
> for Qooxdoo-specific server-side interoperability, I am happy to
> assist with a Java port of the server-side code.

Hi all,

this is exciting. I agree with Ben. Let's define a protocol (preferrably
using JSON-RPC) and then let people create backends. How great it will
be if I can reuse the XML GUIs for several backends...

I would propose that a server should do the following:

- accept GET and POST requests,
- authenticate the user (with a standard user/password parameter),
- do basic security stuff (for example, prevent code injection in
parameters),
- convert JSON data in the parameters into native data structures
- call an named object and object method (for example,
"bibliography.getRowsBySql") - this could be a java object or a php
object - objects could also be template files which return HTML
- return data, indicating the mimegtype of the data (for example,
text/json, text/javascript, text/plain, text/html, x-application/xul,
text/xml, or what have you)

This requires a data binding class on the client side. Until the
QxTransport Classes are ready, there is dojo.io.bind() from the
dojotoolkit. This class would call
"http://www.server.org/qxserver.php?_procedure=foo.bar&arg1=['blub','blah']&arg2={first:'nee',second:34}&_dataformat=json"
or something like this. Are there specifications by JSON-RPC? There is
an implementation in the dojotoolkit.

Concerning the name: what about simply "QxServer"? I would, however,
always have dojo built in, too.

An XML - Format has already been defined by QxBuilder, I propose to just
take it over.

Also, the whole thing should be able to generate documentation with
doxygen.

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

[panyasan]

And I forgot to add: and as Christoph wrote, it is important to write
the backend part with hooks and plug-ins, so that everybody can reuse
their previous components. Maybe we can even agree on common interfaces
in php and java. In seperate config files, users could then specify
callbacks to legacy code which does the authentication, configuration,
etc. Does this make sense?

Christian Boulanger schrieb:

> Hi all,
>
> this is exciting. I agree with Ben. Let's define a protocol
> (preferrably using JSON-RPC) and then let people create backends. How
> great it will be if I can reuse the XML GUIs for several backends...
>
> I would propose that a server should do the following:
>
> - accept GET and POST requests,
> - authenticate the user (with a standard user/password parameter),
> - do basic security stuff (for example, prevent code injection in
> parameters),
> - convert JSON data in the parameters into native data structures
> - call an named object and object method (for example,
> "bibliography.getRowsBySql") - this could be a java object or a php
> object - objects could also be template files which return HTML
> - return data, indicating the mimegtype of the data (for example,
> text/json, text/javascript, text/plain, text/html, x-application/xul,
> text/xml, or what have you)
>
> This requires a data binding class on the client side. Until the
> QxTransport Classes are ready, there is dojo.io.bind() from the
> dojotoolkit. This class would call
> "http://www.server.org/qxserver.php?_procedure=foo.bar&arg1=['blub','blah']&arg2={first:'nee',second:34}&_dataformat=json"
> or something like this. Are there specifications by JSON-RPC? There is
> an implementation in the dojotoolkit.
>
> Concerning the name: what about simply "QxServer"? I would, however,
> always have dojo built in, too.
>
> An XML - Format has already been defined by QxBuilder, I propose to
> just take it over.
>
> Also, the whole thing should be able to generate documentation with
> doxygen.
>
> 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]

>
> I would propose that a server should do the following:
>
> - accept GET and POST requests,
> - authenticate the user (with a standard user/password parameter),
> - do basic security stuff (for example, prevent code injection in
> parameters),
> - convert JSON data in the parameters into native data structures
> - call an named object and object method (for example,
> "bibliography.getRowsBySql") - this could be a java object or a php
> object - objects could also be template files which return HTML
> - return data, indicating the mimegtype of the data (for example,
> text/json, text/javascript, text/plain, text/html, x-application/xul,
> text/xml, or what have you)

pythonbackend: turbogears 0.9 :-)

do you really plan to develop a backend with these features? this is a
whole applicationserver. i don't know the PHP world, but with java and
python you have lots of them.


</usc>


-------------------------------------------------------
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:
> pythonbackend: turbogears 0.9 :-)
>
> do you really plan to develop a backend with these features? this is a
> whole applicationserver. i don't know the PHP world, but with java and
> python you have lots of them.
Yes, but the time to learn java and python, and these programms plus
rewrite existing business logic is much more work than writing a simple
framework which does this stuff. also, hosting environments usually only
offer PHP and therefore java and python solutions are out of the reach
of users without a root server.

C.


-------------------------------------------------------
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

[Ben Alex-5]

Hi everyone

>> - authenticate the user (with a standard user/password parameter),
>> - do basic security stuff (for example, prevent code injection in
>> parameters),
I would definitely advocate the use of BASIC authentication as the
standard authentication approach. That way we don't need to do anything
unusual in terms of security, and we hook into an existing RFC-mandated
standard. Digest and certificate are two other alternatives, but digest
is generally suboptimal as it requires server side sessions to store the
nonce value. Certificates (X509) are great, if you have a clever way of
integrating with them.

In terms of authorization, like protecting particular service endpoints
or the other Java layers that it calls, this should be the
responsibility of the server and be beyond the scope of the Qooxdoo
Server API. Well, maybe we should specify a particular exception to be
thrown if the user is unauthorized or fails to authenticate, and also
provide a way of querying roles associated with the user. Something like:

public String[] authenticate(String username, String password);

With the String[] being a list of roles, and those roles being unable
and identifiable by Qooxdoo client-side widgets, such as being able to
hide or disable various UI controls.

I am happy to discuss security in a depth and develop a security
protocol for this integration API, as I've got a background in it due to
my involvement leading the Acegi Security project
(http://acegisecurity.org).

>> - convert JSON data in the parameters into native data structures
>> - call an named object and object method (for example,
>> "bibliography.getRowsBySql") - this could be a java object or a php
>> object - objects could also be template files which return HTML
This is already done for free by the various JSON-RPC implementations
out there. See http://json-rpc.org/wiki/implementations for a full list
of implementation. Note there are four PHP implementations, which should
make the PHP users on this list happy! :-)

>> - return data, indicating the mimegtype of the data (for example,
>> text/json, text/javascript, text/plain, text/html, x-application/xul,
>> text/xml, or what have you)
>
I don't see why you'd need to deal with this. JSON just returns a
JavaScript object that the client can eval() directly.

> do you really plan to develop a backend with these features? this is a
> whole applicationserver. i don't know the PHP world, but with java and
> python you have lots of them.
I'd imagine the main value-add of the Qooxdoo Server API is:

- Selecting, standardising on and reusing existing technologies as far
as possible (eg BASIC authentication, JSON-RPC, XML etc)
- Using XML to define the Qooxdoo application, but without limiting the
ability to use hand-crafted JavaScript
- Well-defined server endpoints for key infrastructure integration
functions (eg a JSON-RPC service name and method signature for things
like callbacks, obtaining a list of roles etc)
- Tooling support for XML definition (namely XML schemas etc to permit
type-safe validation and auto-completion in XML editors)
- Design patterns (such as using data transfer objects, client-side
editors to edit the transfer objects, how localization is handled,
layout of directory structures etc)
- Sample application showing full interoperability
- Ultimately developing GUI tools to assist rapidly build a Qooxdoo
application, dialog editors etc using the XML syntax

As can be seen, most of this is not server-side specific at all. The
server-side platform would only need to implement the well-defined
server endpoints in the preferred language. This should be relatively
easy to achieve and minimise porting efforts. Are others seeing this API
as doing something more? Less? Other ideas? Maybe the key Qooxdoo
authors could comment on the viability of using XML in this manner
(versus hand-crafting JavaScript)?

Best regards
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

[ChristophDorn]

I think we need to split this into two projects as I mentioned in one of my other messages.

Writing an application server (which this will be) is a tall order. Not in the sense that the coding is necessarily hard to do, but gaining community support and interest in it and growing its featureset in a standard and controlled manner. There are already a lot of frameworks out there that we can integrate with much faster than writing our own. It also gives us access to already existing communities.

IMHO we should focus on a phased approach that will publish components as they become available so they can be used much faster than a complete framework. Something like this:

1) XML standard to describe a qooxdoo app
2) Implement the loading of the XML into a qooxdoo application
3) Define and implement an event callback system that can trigger server-side code based on UI events
4) Integrate the above components with several popular frameworks

We can then do several things. We can standardize and abstract the XML to encompass other frameworks like dojo. Same for the callback system. We could also based on all common requirements develop a specification that a server-side framework should follow to fully support our UI XML standard. If no other framework steps up to the plate to implement the standrd fully we can write our own extensions for other frameworks or we can then decide to implement our own.

The original proposal was to develop a standard as to how a complex qooxdoo application should be implemented. My main interest is in qooxdoo at the moment. Sure a general framework would be great and I am sure we will head in that direction long-term but I am looking for a solution now that I can implement into already existing applications.

A phased approach will keep our options open and we can work on a framework if it is necessary but lets prioritize our milestones so that we can release viable components soon.

I like the idea of calling it QxServer. Maybe "Qooxdoo Server Project". Emphasis should be on supporting and using as much existing technology as possible. Lets leverage what already exists.

If this reaches general consensus I will draw up a diagram as to how I think it should be structured/architected from a high-level perspective.

Christoph

[panyasan]

Hi Christoph,

ChristophDorn schrieb:
> I think we need to split this into two projects as I mentioned in one of my
> other messages
> Writing an application server (which this will be) is a tall order. Not in
> the sense that the coding is necessarily hard to do, but gaining community
> support and interest in it and growing its featureset in a standard and
> controlled manner. There are already a lot of frameworks out there that we
> can integrate with much faster than writing our own. It also gives us access
> to already existing communities.
>  
If there is one, I will happily take it, we don't need to reinvent the
wheel. I have so far not found one that can do the things I have
outlined. But maybe more research is needed.

> IMHO we should focus on a phased approach that will publish components as
> they become available so they can be used much faster than a complete
> framework. Something like this:
>
> 1) XML standard to describe a qooxdoo app
> 2) Implement the loading of the XML into a qooxdoo application
> 3) Define and implement an event callback system that can trigger
> server-side code based on UI events
> 4) Integrate the above components with several popular frameworks
>  

Looks excellent to me.
> We can then do several things. We can standardize and abstract the XML to
> encompass other frameworks like dojo. Same for the callback system. We could
> also based on all common requirements develop a specification that a
> server-side framework should follow to fully support our UI XML standard. If
> no other framework steps up to the plate to implement the standrd fully we
> can write our own extensions for other frameworks or we can then decide to
> implement our own.
>  
Agreed!
> The original proposal was to develop a standard as to how a complex qooxdoo
> application should be implemented. My main interest is in qooxdoo at the
> moment. Sure a general framework would be great and I am sure we will head
> in that direction long-term but I am looking for a solution now that I can
> implement into already existing applications.
>  
Yes, let's start with Qx, and integrate others once that works.

> A phased approach will keep our options open and we can work on a framework
> if it is necessary but lets prioritize our milestones so that we can release
> viable components soon.
>
> I like the idea of calling it QxServer. Maybe "Qooxdoo Server Project".
> Emphasis should be on supporting and using as much existing technology as
> possible. Lets leverage what already exists.
>
> If this reaches general consensus I will draw up a diagram as to how I think
> it should be structured/architected from a high-level perspective.
>  

That would be great. If the framework is modularized, each of us can
take over a component and implement it according to a common standard
(class structure, coding style, etc.).

Thanks for taking the lead!

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