JS Databinding in SEMF

While I am working on SEMF Databinding which synchronize HTML Element and Data XML, I thought it would be great if we follow a specified pattern on it. Although IE provide good databinding intergrated with the browser with the concept of XML Data Island, I have to think of some thing that work cross-browser. So I am suggesting a JavaScript Databinding Framework for SEMF like following..

1. The format of the Data XML is as following.
<xml>
<data> <!-- IE Needs another wrapper to identify this as data-->
    <data> <!-- Keeps the data variables -->
         <attr val="dataVar1">
             <!--this is an example of data variable.., It has direct attributes name, country and sports -->
                    <attr val="3"> <!-- the actual id of the data-->
                         <attr val="name">
                             Test1 <!-- just a simple value..-->
                         </attr>
                         <attr val=""> <!-- country is an another data object -->
                             <attr val="name">
                                 Country1
                             </attr>
                         </attr>
                         <attr val="sports"> <!-- This is an array -->
                             <sports>
                                    <attr val="1">
                                         Sport1
                                    </attr>
                                    <attr val="2">
                                         Sport2
                                    </attr>
                             </sports>
                         </attr>
                    </attr>
         </attr>
    </data>
    <page> <!-- Keeps page variables -->
         <attr val="pageVar1">
             varValue1
         </attr>
         <attr val="pageVar2">
             varValue2
         </attr>
    </page>
</data>
</xml>
2. It has mapped a property to a particular XML Data Component..
3. HTML elements are associate with properties.
E.g.
<input databind="property1"/> which will bind the elmeent to property which is mapped to a particular XML Data Component.
4. Repeater elements are defined to behave as pivots on repeating XML data structures.
E.g.
<span repeaterpivot="1">
    <input databind="property1">
</span>
The repetition will be happened,

* If the property1 is associated with a data variable AND
* If the data variable associated with the property1 has several ids OR/AND
* The final attribute referenced by the property is an array

E.g.
if the property1 is referening to "@dataVar1.sports" the repetition will be happened following way.
<span repeaterpivot="1">
    <input databind="property1" value="Sport1">
</span>
<span repeaterpivot="1">
    <input databind="property1" value="Sport1">
</span>
This is because the @dataVar1.sports is an array and the array has several elements.

But if the property is refering to "@dataVar1.name" there would be only 1 entry since it is not an array. But it dont need to be a array to make a repeat as mentioned in the above points.
If dataVar1 had have some other ids and they had entries for name, then the @dataVar1.name would repeat the same way like below.

<span repeaterpivot="1">
    <input databind="property1" value="Test1">
</span>
<span repeaterpivot="1">
    <input databind="property1" value="Test2">
</span>

These would be the basic properties of the Databinding Framework shifted with the SEMF. The implementation is almost done except for solving some very basic things. Hope it would be finished by the end of this week making SEMF to finish its first stage.

SEMF is waking up

After having thousands of drafts, planning, designing the SEMF is right now in the middle of the Implementations. The good part of the work already have finished. But Things are not seems easy as it will takes some more time than we what we really have. Projects submission were postponed for 2 months just giving away some time to test our luck.
Since I am doing working on Page Designer (Virtually the main component of the project). I should document it status right now. But for sure it s shaping nice. And it is just about to start breath.
Here What I have done so far with Page Designer..

1. Drag & Drop mechanism to add web component to the page..
2. Introduce containers for components(Components can contain containers) to design the layout.
3. Nice tabbed grouped properties for customizations of the component.
4. Nice Toolbar, but only one button working right now.
5. Code generations. Specially generations which doesnt involve scripting(Well, read the next point) is already completed..
6. Introducing a scripting language ( We call it 'SEMF Script') for databinding and action handling.
7. Tokenizers and passers were written for the SEMF Scripting. With full aware of token errors, parse errors.
8. Halfly written semantic handler for the parse tree which is not tested yet. This will be impossible to test untill some good part of the project is completed..
9. Generate PHP code and/Or javascript code for Databinding and action handling.
10. Built-in HTML Editor for HTMLText component using TinyMCE..
11. Good media Uploader - Store. (There are cut/copy and paste functionalities there)
12. Some good page lay outing for the Page Designer Environment itself.

Right now I am working on a design and a parallel implementation for databinding and action handling in client side. (That is javascript code generation.) I took some time to finish it, because i thought it would be both difficult and simple..

Things to do - Most Important thing running on my head now
===========================================
1. Finish a rough implementation of complete code generation (i.e php and javascript code for both client side and server side)
2. Test it.
3. Some rough unit testing framework at least at the end just for ease the further development if it is necessary.
4. Functions for support page navigation..
5. Component Editor if there is some time left. Just 2 more weeks.
6. Documentation mechanism.
7. Good Tool tip viewer.

There are a lot even only for the Page Designer. And there are many left(Virtually all, that were there when we start this project) for other components of the Project as well. So I stop here hoping I will update the projects with some new details in next few days.

Back to YUI

I thought it is better go back to YUI http://developer.yahoo.com/yui/. As it seems a pain to write all these javascript by hand.
With YUI I believe we can have a great advantages on,

1. More abstracted AJAX Calls - to support many browsers
2. Nice effects in animation
3. Panels provided by the YUI
4. Drag and Drop effects


Anyway we may need to do some editing or atleast hand-written javascripts to customize them. Hope we will find some more quick ways.

Moving from Desktop to Browser

When Google first introduce Gmail with AJAX, people tend to get away with Desktop email clients like Thunderbird, Outlook. And it was continuing the move from desktop to browser throughout the past few years.

SEMF is also an attempt to getting close to the browser rather than the desktop. It should work right if we do the things fine..

SEMF <--> Portlet

SEMF has a relationship to Portlet just because they both provide pluggable user interface components.

Anyway the primary target of SEMF and Portlet are different. As portlet try to provide a standard API to communicate between portals in different sites, SEMF is not intend to interoperable with some other implementations. as SEMF is unique:!

Primary Target of providing little web based windows which are analogue to portlet is just allow the users to provide different ways of representing data which is stored in a database.

Well. SEMF is more towards how we represent a given kind of data rather than how it would be processed or how it would be interoperate..

Efficiency is a main requirement of SEMF. We found most of the implementations of Portlets are very heavy. They used to generate the code at runtime which is a big bottleneck in performance. Our approach is to generate the code at design time and publish the generated code which have very little processing to do at runtime.

So it is very little that we can follow from Portlet in here. So we should write our own portlet engine.

The First Post

Hi,
Well I decided to start a blog for our project which will be more useful than the group we have (although it is also not pack as much;).
So what should be posted here and what should be posted in the group is the next question. Well my selection criteria is this.
Here we should present our independent ideas, feelings and and the studies of the environment regarding the project. So the viewers should people this is a bunch of resources that they can have a good idea of our project, the project flow and the final project.
Whereas the Google group can be used as a discussion forum. If we found an important, controversial thing, we can just that move that in to the group and do our discussions there.

And to remember one thing what ever we do, the real value of that doesn't solely depend on the greatness of the product, but it depend more than 90 percent on the things that we say about it.

So lets start the work.!