[TYPO3-hci] GUI Toolkit Qooxdoo

[Patrick Broens]

Franz Koch wrote:
> Hi Patrick,
>>> first. I just stumbled over this list and find it very interessting. 
>>> Unfortunately I'm to late to join the team :(
>>
>> Why?
> 
> I read somewhere that the group working on this is "closed" or something 
> like that.
As far as I know this was concerning a HCI group from the Copenhagen 
Business School.
> 
>> The meaning of my posting about Qooxdoo is not to promote this 
>> framework, but the way they did it. TYPO3 lacks a GUI framework, and 
>> in my opinion we need one. Most of the things done by Qooxdoo can also 
>> be done with PHP, which I prefer also, together with AJAX. Don't let 
>> there be a misunderstanding about that. Qooxdoo is a good place to 
>> start with when building a GUI framework. They thought about a lot of 
>> functionality  that has to be in a framework, which we can adopt, be 
>> it in PHP/AJAX. Have a look at their API to see what I mean.
> 
> Sorry - I misunderstood your post and totally agree with the missing GUI 
> framework.
I can understand. That's why I posted this to clarify some things.
> 
>> I see a lot of advantages working with a GUI framework. All backend 
>> page building will be done through this framework, which makes it very 
>> easy to change the skins and the interfaces, because it will be all 
>> done OO, server and client side. Right now there is only little 
>> support in some classes to use some 'GUI' functionality. For instance, 
>> backend modules almost always have their layout hardcoded, which is 
>> not preferrable. It's all about consistency and reusability.
> 
> +1
> 
>> DHTML/Web2.0 stuff are not only nice gimmics. It makes the backend 
>> work faster, especially with AJAX. Pages are not reloaded completely. 
>> Another advantage is you can give the user the functionality of 
>> applications they're already used to, like drag and drop, column 
>> resizing in tables for better views, the way menu bars are handled 
>> etc. TYPO3 needs to adopt the functionality users know from other 
>> applications, not inventing other ways to do it.
> 
> I know how AJAX works and it's advantages - but it always should be 
> optional in my eyes. 
True, but that's the nice thing about AJAX. If Javascript is not on, you 
can switch back to a complete reload of the page by using a fallback 
option. The framework needs to cooperate with the user configuration to 
turn this off as well.
And I don't agree that Typo3 "needs" to adopt
> functionality. It "should" adopt functionality where it is suitable and 
> use own or modified functionality where it's necessary.
If there is no alternative, yes. Usability is about what people know, 
how to handle things, what is common. There will always be things that 
are not quite common to do, so we have to create our own or modify 
something that is close to the original. Before the development there 
has to be a lot of investigation to see how other applications handle 
things and what is the most common way to handle it in different OS's. 
This almost has to be done with every aspect of the GUI framework.
> 
> Speaking of a faster backend. XHTML is also a point I'd like to see in a 
> future BE where the pagetree is a nice nested UL etc. I allready tryed 
> hacking the pagetree rendering, but didn't get it work as inteded (had 
> problems with the php-code). But I know that it works, as ezPublish 
> shows and maybe many other CMS and applications.
+1, I think everybody is aware of that.
> 
>> The GUI framework can always be enhanced, according to the wishes of 
>> developers. If they invent something that can be usefull in the GUI 
>> framework, we have to embed it.
> 
> It'll be good if the framework would be something like a service but 
> with the possibility to configure the framework on BE-user/BE-group 
> basis (which templates, which service-part a 'renderlet' should use,...).
> 
That's how I think about it as well. The GUI framework should be able to 
work with the user/group configuration like TYPO3 does now.

Patrick