Application Definition Language

[skitsanos]

Guys,

it was quite fine when there was about 50 AJAX frameworks, but today, when there is like more than 200 already you can go nuts. I was looking for a long time into how Backbase, Adobe Flex and Bindows trying to handle their "application construction" tasks, figured out pros and cons of all of them, same time I was looking into how Yui-Ext was growing and what other AJAX/RIA frameworks available. Obviously even by being big fan of Backbase paying $6,000 license fee for application server it is not what I really want to do, for sure neither you guys.

So what is all about. While you guys had (hopefully) nice xmas holidays I had a little dig into Yui-ext and couple of other things. The reason I started digging is that I don’t want to waste so much valuable time on tons of JavaScript lines. I want to have one unified language that allows me describe application functionality (since I do webware applications as primary source of income). Easiest way to describe application functionality is to use some sort of mixture between XML and HTML and leave JavaScript only for pleases where it is needed – for linking GUI elements, events handling and etc. So, basically I had in mind many years of UI programming I did for Windows, OS/2, Linux and others and wanted to have simple “language” that will help me to build webware applications quicky enough.

First two things I was desperate to have supported are Application Layouts and Windows. And keep in mind I really want to minimize my time on JavaScript coding.

So what I did:

1) Application Layouts
<gf:Layout id="ltApplication">
<gf:LayoutPanel initialSize="35" location="north" split="false">
<span style="color:#98c0f4; font-size:1.8em;">Grafeio UI demonstration</span>
</gf:LayoutPanel>

<gf:LayoutPanel autoScroll="true" collapsible="true" initialSize="200" location="west" split="true" title="Actions" titlebar="true">
<gf:Accordion id="acc1">
<gf:AccordionPanel id="panel1" title="Panel #1">Here is the content for Panel #1</gf:AccordionPanel>

<gf:AccordionPanel id="panel2" title="Panel #2">Here is the content for Panel #2</gf:AccordionPanel>

<gf:AccordionPanel id="panel3" title="Panel #3">Here is the content for Panel #3</gf:AccordionPanel>
</gf:Accordion>
</gf:LayoutPanel>

<gf:LayoutPanel autoScroll="true" location="center">

</gf:LayoutPanel>

<gf:LayoutPanel initialSize="20" location="south" split="false">
© 2007, Evgenios Skitsanos.
</gf:LayoutPanel>
</gf:Layout>

2) Windows
<gf:Window id="wndSample" title="Sample Window via Yui-Ext">
<div>Sample Window</div>
</gf:Window>
(Bigger sample you can see on http://www.mywdk.com/labs/grafeio/)

As you can see, instead writing all of this JavaScript and tons of definitions, I automated it with custom “language”. This sample shows you how to define Application Layout, to embed Accordion component into one of the content panels, and the last sample just renders Window.

[tryanDLS]

Maybe I'm missing the point:

1) You don't want to code javascript, but you wrote an abstraction layer on top of yui-ext - in javascript.
2) You added more processing time to page building because now you have to parse your new syntax.
3) Everytime there's a change/enhancement to yui-ext, there's a potential change to your layer. Instead of adding parms to a method call in yui-ext, you're now adding an HTML attribute to your syntax and you have to translate that to the appropriate yui-ext argument.
4) You now have another toolset to learn and keep documented.
5) While you only want to build Layouts and Windows, it's not likely that anybody's going to use your syntax since they can't use it for the rest of yui-ext, unless you add more syntax to your tool.
6) If you think you're going to make this generic for multiple frameworks, you now have all these issues for multiple frameworks.
7) Instead of buiding web apps, now you're supporting another tool. As soon as you implement this for a client, he's gonna say 'I want a tree'. Now not only do have to learn how do trees in yui-ext, you have to build your tool to handle them - more javascript.

This sounds like just another 'build your apps without writing code - anybody can do it' marketing pitch. Not to say it can't work - IBM has been selling this type of silliness for years!

Just my .02 from a developer who's seen more than enough 'point/click, drag/drop' tools. Bottom line, building applications means writing code!

[skitsanos]

well, thanx for a feedback anyway. i don't want to argue here about my own pros and cons, but the "toolset" as you called it really saves nervs and time after all, at least for me.

first of all it is not only based yui-ext. yui-ext is just part of it.

second, making layouts and windows wasnt a primary target for me, instead i want to save time on development, and indeed i managed it.

this UI framework not entirely build on top of Yui-Ext, so i have to "track" changes as well on other bits, but hey, it is not your headache. It is always about personal preferences, you like the concept/idea - you using it, you dont - well, mind your own way of doing things.

In my way i only code in language that looks like XML after all, and all rendering to what you actually see is done on-fly automatically. So there is no such a thing like "more processing time to page building", at least not for client side.

and if client wants trees or whatever else, - no problem, he can have it. wants charting? or whatever else, same, i use same application definition language, client don't care, he always gets what he wants.

and my personal recomendation for you, sir, - look into Backbase and try to understand why they are #1 AJAX Framework.

my idea was to help others a little, not to get into arguing sort of " this , dude, you code stinks!". so if you like the concept or want to comment on it, you welcome, you hate it - there is a button on right-upper corner to solve issues like this.

[tryanDLS]

No need to get cranky and use inappropriate language just because someone disagrees with your viewpoint.

Funny how the first review of frameworks I came across had a comment from you saying 'hey what about Backbase?' [url]http://www.maxkiesler.com/index.php/weblog/comments/round_up_of_50_ajax_toolkits_and_frameworks/[/code]

If you want to be a shill for Backbase, that's fine, but be up front about it.

[skitsanos]

well, you wrong one more time.

yea, there are at least 3 frameworks i like, - backbase, flex and bindows, so what? i don't work or trying to do any favor for none of their authors/owners, so do me a favor, cut it off. want to help moving your stuff, share it. i like backbase and flex because they are documented perfectly, have tons of impressive samples and main point is that frameworks do the job.

[Animal]

It does seem tortured to get XML to encapsulate UI functionality with all it's asynch events, and procedurality.

We investigated Backbase, and gave up. It's a case of square peg, round hole.... It's trying to make "procedural" XML to handle events. It's VERY difficult to script the widgets to make them do what you want.

The whole point ot OO development, is that you have OBJECTS which you can request services from. In this case widgets with methods. It's simple and effective, so why stifle the developer by fossilizing the widgets in a layer of XML?

[skitsanos]

let's see what is going to be in v.4.0 of Backbase that is comming in near future as i understood.

as fro scripting widgets, yes, you are right, but the way i script them is exactly in the way it could be done manually, so in my case there is no difference or you code it by hands or will use this XML like language to code it. It is all about the way of implementing things.

check the Flex or OpenLaszlo for example... there are a lot of things going on "behind", but fancy is the way of "describing" the application. and hey, i never said i will give you something to get rid of coding.

[sjivan]

The XUL approach is indeed similar to Laszlo and Backbase and can help facilitate UI builders. This might be attractive at first glance to a Javascript newbie and someone new to the toolkit but I think that if one is to develop anything more than simple examples they are going to need to get good at Javascript, XUL or not..

The XUL syntax for widgets in fine, but the more important aspect is adding behavior and as Animal states, the use of xml style events seems a little klunky and non object oriented which might lead to not so organized code for larger projects.

I also am skeptical about the comment about the XML tags processing. I cannot see how the XML tags to javascript conversion can be done without parsing and adding overhead to the processing of a page. Dojo is a prime example of how the widget auto parsing kills the performance of larger pages.

Once you've gotten the hang of OO javascript and Java-like organization of classes / behaviour, I think going with just coding yui-ext in Javascript works better from both a code organization and performance perspective. Its not like programming in yui-ext is programming at the lowest level. yui-ext provides solid foundation classes (like Observable) and a great widget library.

I think there is potential for the XUL approach but for it to be successful, it needs to provide a comprehensive widget tag library (like backbase), have a good event handling story and preferably have a UI builder where events can be added to controls (ala VB). This is no easy task but anything less would not really be very useful for real world projects.

Sanjiv

[skitsanos]

thank you for feedback sjivan. defenitelly without having heavy collection of widgets/ui objects, there is no one would pay attention to this thing. one of the catchy moment for backbase for example is that they have 50 UI objects by default and the "language" allows to extend them into any bigger number. I had no luck to try their .Net edition as some of the peopel managed, but i manmaged to make my own on top of their Client Edition.

since most of the ASP.NET applications deployed by me to my cleints using custom build Virtual File System, i will just embedd XML parsing into it...