You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Chandresh Turakhia <ch...@bhartitelesoft.com> on 2007/02/13 11:25:58 UTC
Fw: General questions
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.
>
Re: General questions
Posted by Chandresh Turakhia <ch...@bhartitelesoft.com>.
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" <jo...@hotwaxmedia.com>
To: <de...@ofbiz.apache.org>
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.
>
>
Re: General questions
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
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.