Fw: General questions

[Chandresh Turakhia]

FYI . Bob is from Nexaweb.

Sent: Tuesday, February 13, 2007 2:22 AM
Subject: Fw: General questions


Bob , Ben :

Based on discussion on Ofbiz newsgroup,

Correct me if my understanding is not at best with XAL and Ofbiz.

I would advocate
  a.. Take ftl files from Ofbiz.
    a..    Separate Markup with FTL tags. Now we have 2 XML file. (1) Markup View file  and (2) another file have @ofbiz type id file
    b..    Same ftl file could be regenerated using XSLT combination of (1) and (2)
  b.. Change file (1) change it to .xal file which file (3). I assume all html tags are valid in XAL.
    a.. You may selectively update with better looking controls
    b.. XSLT can update widgets selectively.
    c.. Think about working Ofbiz widgets with nexaweb widgets.
  c.. Use XSLT to merge (3) with (2) to get new .ftl (4) file which are XAL files.
Now we have (4) xal files rendered from ftl files.  It should look better

Atleast it will get xal inside ofbiz. Get visibility

All my ideas may not be best hack but hoping some turn out to be :) Please correct me if there is better approach.

Chand

>> (2) XAL  - Let me talk to Bob from nexaweb, we can help you convert  
>> in mass to XAL-HTML . Think about it.
>
> This looks like a nice tool and it would be great to use it going  
> forward.
>
> I don't like the idea of doing any sort of mass conversion because  
> many pages simply don't need AJAX-like functionality, and it would be  
> best to keep these as simple and multi-browser friendly as possible.  
> Simplicity has other advantages too, like being easier to create and  
> maintain in general.
>

[David E Jones]

I'm keeping this on the dev mailing list only, rather than also  
copying the user mailing list (seems more applicable here).

I guess this email is the more detail part that I asked in the  
message I just sent. Still, any more thoughts would be of interest.

I'd say the best starting point for this would be to do some PoC  
work. We have an HtmlFormRenderer class and similar classes for the  
screen, menu and tree widgets. It would be cool to create  
alternatives for these that would generate XAL for use with the XAP  
stuff. Those along with a default wrapper decorator screen for use  
with these would make it easy for people to reuse existing artifacts  
with XAP.

For the FTL side of thing the best thing would be just create some  
examples, probably pick a couple of screens that would benefit a LOT  
from AJAX, like the find party and find order screens, and create XAL  
versions of them that initially can exist in parallel with the more  
vanilla HTML screens that currently exist.

So, yeah, there are some cool things that could be done with this. I  
wish I had more time to get involved.

BTW, if there is anyone who is planning on attending the upcoming dev  
conference (aka hackathon) on Mar 5-9 and who is interested in  
working on this stuff, let me know and I can add it to the list of  
projects to push on.

-David


On Feb 13, 2007, at 3:25 AM, Chandresh Turakhia wrote:

> FYI . Bob is from Nexaweb.
>
> Sent: Tuesday, February 13, 2007 2:22 AM
> Subject: Fw: General questions
>
>
> Bob , Ben :
>
> Based on discussion on Ofbiz newsgroup,
>
> Correct me if my understanding is not at best with XAL and Ofbiz.
>
> I would advocate
>   a.. Take ftl files from Ofbiz.
>     a..    Separate Markup with FTL tags. Now we have 2 XML file.  
> (1) Markup View file  and (2) another file have @ofbiz type id file
>     b..    Same ftl file could be regenerated using XSLT  
> combination of (1) and (2)
>   b.. Change file (1) change it to .xal file which file (3). I  
> assume all html tags are valid in XAL.
>     a.. You may selectively update with better looking controls
>     b.. XSLT can update widgets selectively.
>     c.. Think about working Ofbiz widgets with nexaweb widgets.
>   c.. Use XSLT to merge (3) with (2) to get new .ftl (4) file which  
> are XAL files.
> Now we have (4) xal files rendered from ftl files.  It should look  
> better
>
> Atleast it will get xal inside ofbiz. Get visibility
>
> All my ideas may not be best hack but hoping some turn out to be :)  
> Please correct me if there is better approach.
>
> Chand
>
>>> (2) XAL  - Let me talk to Bob from nexaweb, we can help you convert
>>> in mass to XAL-HTML . Think about it.
>>
>> This looks like a nice tool and it would be great to use it going
>> forward.
>>
>> I don't like the idea of doing any sort of mass conversion because
>> many pages simply don't need AJAX-like functionality, and it would be
>> best to keep these as simple and multi-browser friendly as possible.
>> Simplicity has other advantages too, like being easier to create and
>> maintain in general.

[Chandresh Turakhia]

Agreed.

So whats the task for me.- ( Talking like developer ). Let me know which
file and what to change.

Quick question from XAL experts ) : XAL works in html , for sure . But what
steps I need to take to make it work.

I might need XAP runtime too in classpath.

Chand

----- Original Message -----
From: "David E. Jones" <[hidden email]>
To: <[hidden email]>
Sent: Tuesday, February 13, 2007 2:44 AM
Subject: Re: General questions

>
> I'm keeping this on the dev mailing list only, rather than also  copying
> the user mailing list (seems more applicable here).
>
> I guess this email is the more detail part that I asked in the  message I
> just sent. Still, any more thoughts would be of interest.
>
> I'd say the best starting point for this would be to do some PoC  work. We
> have an HtmlFormRenderer class and similar classes for the  screen, menu
> and tree widgets. It would be cool to create  alternatives for these that
> would generate XAL for use with the XAP  stuff. Those along with a default
> wrapper decorator screen for use  with these would make it easy for people
> to reuse existing artifacts  with XAP.
>
> For the FTL side of thing the best thing would be just create some
> examples, probably pick a couple of screens that would benefit a LOT  from
> AJAX, like the find party and find order screens, and create XAL  versions
> of them that initially can exist in parallel with the more  vanilla HTML
> screens that currently exist.
>
> So, yeah, there are some cool things that could be done with this. I  wish
> I had more time to get involved.
>
> BTW, if there is anyone who is planning on attending the upcoming dev
> conference (aka hackathon) on Mar 5-9 and who is interested in  working on
> this stuff, let me know and I can add it to the list of  projects to push
> on.
>
> -David
>
>
> On Feb 13, 2007, at 3:25 AM, Chandresh Turakhia wrote:
>
>> FYI . Bob is from Nexaweb.
>>
>> Sent: Tuesday, February 13, 2007 2:22 AM
>> Subject: Fw: General questions
>>
>>
>> Bob , Ben :
>>
>> Based on discussion on Ofbiz newsgroup,
>>
>> Correct me if my understanding is not at best with XAL and Ofbiz.
>>
>> I would advocate
>>   a.. Take ftl files from Ofbiz.
>>     a..    Separate Markup with FTL tags. Now we have 2 XML file.  (1)
>> Markup View file  and (2) another file have @ofbiz type id file
>>     b..    Same ftl file could be regenerated using XSLT  combination of
>> (1) and (2)
>>   b.. Change file (1) change it to .xal file which file (3). I  assume
>> all html tags are valid in XAL.
>>     a.. You may selectively update with better looking controls
>>     b.. XSLT can update widgets selectively.
>>     c.. Think about working Ofbiz widgets with nexaweb widgets.
>>   c.. Use XSLT to merge (3) with (2) to get new .ftl (4) file which  are
>> XAL files.
>> Now we have (4) xal files rendered from ftl files.  It should look
>> better
>>
>> Atleast it will get xal inside ofbiz. Get visibility
>>
>> All my ideas may not be best hack but hoping some turn out to be :)
>> Please correct me if there is better approach.
>>
>> Chand
>>
>>>> (2) XAL  - Let me talk to Bob from nexaweb, we can help you convert
>>>> in mass to XAL-HTML . Think about it.
>>>
>>> This looks like a nice tool and it would be great to use it going
>>> forward.
>>>
>>> I don't like the idea of doing any sort of mass conversion because
>>> many pages simply don't need AJAX-like functionality, and it would be
>>> best to keep these as simple and multi-browser friendly as possible.
>>> Simplicity has other advantages too, like being easier to create and
>>> maintain in general.
>
>