Any plan to allow field widgets like inside ?

[Jonathon -- Improov <jo...@improov.com>]

The problem I'm facing now is that form widgets always have the start and end wrappers (<table 
cellspacing...> and </table). It is not possible to mix fields from one form into another form 
done in ftl.

Attributes skip-start and skip-end only remove the <form> wrapper.

Getting form widgets to say skip-table could solve this problem, though it's not intuitive to use 
form widgets as field widgets. Better to use field widgets in screen widgets instead. However, 
this approach could be a quick interim fix.

Another problem is the colspan for <td>. Maybe we can make that variable.

Field widgets like <drop-down> are fantastic. It's a pity we can't use them inside of creative 
displays written in ftl.

Si Chen did some FreeMarker macros for these, I believe. But if we're gonna strongly advocate 
widget usage, I think we need to fill that void in screen widgets. Going the FreeMarker macros 
route would basically rewrite much of what is already provided by field widgets.

Maybe have a generic "group of fields" widget via <fields>?

Jonathon

Re: Any plan to allow field widgets like inside ?

[Jonathon -- Improov <jo...@improov.com>]

Ok, then any plans to rewrite eCommerce screens as screen widgets?

If that was going backwards... ah, this has been mentioned before. Won't waste my tired self 
now... long day.

Jonathon

BJ Freeman wrote:
> seems your going backwards.
> remove the ftl and use screen widgets that include formwidgets.
> add a class (style) and use the css for aligning tables.
> 
> Jonathon -- Improov sent the following on 12/2/2007 8:48 PM:
>> The problem I'm facing now is that form widgets always have the start
>> and end wrappers (<table cellspacing...> and </table). It is not
>> possible to mix fields from one form into another form done in ftl.
>>
>> Attributes skip-start and skip-end only remove the <form> wrapper.
>>
>> Getting form widgets to say skip-table could solve this problem, though
>> it's not intuitive to use form widgets as field widgets. Better to use
>> field widgets in screen widgets instead. However, this approach could be
>> a quick interim fix.
>>
>> Another problem is the colspan for <td>. Maybe we can make that variable.
>>
>> Field widgets like <drop-down> are fantastic. It's a pity we can't use
>> them inside of creative displays written in ftl.
>>
>> Si Chen did some FreeMarker macros for these, I believe. But if we're
>> gonna strongly advocate widget usage, I think we need to fill that void
>> in screen widgets. Going the FreeMarker macros route would basically
>> rewrite much of what is already provided by field widgets.
>>
>> Maybe have a generic "group of fields" widget via <fields>?
>>
>> Jonathon
>>
>>
>>
> 
> 

Re: clustering with tomcat and

[David E Jones <jo...@hotwaxmedia.com>]

You should try the latest OFBiz from SVN. There are various recent  
improvements in this area:

1. now using Apache DBCP instead of Minerva
2. problem with transactions, synchronization, and locking in EE  
sequencer
3. problem with concurrency and locking in async and scheduled  
services (this was just fixed a couple of days ago)

-David


On Dec 3, 2007, at 3:35 AM, robert.ruprecht@gmx.de wrote:

> Dear all,
>
> We are quite far in evaluating ofbiz for a heavy load system on the  
> ecommerce (cluster with at least two application nodes and a HA- 
> Postegres database )
> This is working fine in most cases and when there is little load on  
> the systems.
>
> But there are two things we didn't succeed to solve yet:
>
> - session replication tomcat to tomcat:  although we succeeded to  
> replicate session with an standard Tomcat we do not succeed to  
> replicate sessions between two embedded ofbiz-tomcats  - is the  
> implementation of the embedded tomcat different of the standalone  
> version ?
>
>
> - minerva XA-Pool (?)  - during our tests we found out that the  
> connection pooler works not work properly if we test heavy load on  
> two cluster nodes and one database (Postgres 8.1) - the database  
> gets locked by one of the instances( could not commit...), most  
> often it happens on the sequenceID table and then all the  
> connections from the pool get used.  Bad thing is the even if we  
> stop the locking instance the other node does not recover.
> (we tested also with the minerva from the hotwax media-repository)
>
>
> How we test:
> - we run some end-to-end tests with a testing tool( browse catalog,  
> register users, login/out, add to basket, send orders, run services  
> in the backend)
> - put some additional io-load on the database node
>
> ...and wait few seconds/minutes to see it crashing
> If there is no additional load on the database node it locks afte  
> two days latest ...
>
>
> So I'll be really happy to hear that there is some experience in  
> clustering   ofbiz for load and availability reasons.
>
> Thanks
> Robert
> -- 
> GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
> Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

clustering with tomcat and

[ro...@gmx.de]

Dear all, 

We are quite far in evaluating ofbiz for a heavy load system on the ecommerce (cluster with at least two application nodes and a HA-Postegres database ) 
This is working fine in most cases and when there is little load on the systems. 

But there are two things we didn't succeed to solve yet: 

- session replication tomcat to tomcat:  although we succeeded to replicate session with an standard Tomcat we do not succeed to replicate sessions between two embedded ofbiz-tomcats  - is the implementation of the embedded tomcat different of the standalone version ?


- minerva XA-Pool (?)  - during our tests we found out that the connection pooler works not work properly if we test heavy load on two cluster nodes and one database (Postgres 8.1) - the database gets locked by one of the instances( could not commit...), most often it happens on the sequenceID table and then all the connections from the pool get used.  Bad thing is the even if we stop the locking instance the other node does not recover.
(we tested also with the minerva from the hotwax media-repository) 


How we test: 
- we run some end-to-end tests with a testing tool( browse catalog, register users, login/out, add to basket, send orders, run services in the backend)
- put some additional io-load on the database node 

...and wait few seconds/minutes to see it crashing  
If there is no additional load on the database node it locks afte two days latest ...


So I'll be really happy to hear that there is some experience in clustering   ofbiz for load and availability reasons. 

Thanks
Robert
-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

Re: Any plan to allow field widgets like inside ?

[Jonathon -- Improov <jo...@improov.com>]

This is a large ML for a large community! I miss tons and misinterpret lots everyday. :)

Someone has expressed interest in this. :( I hope this becomes a core part of OFBiz instead.

Jonathon

BJ Freeman wrote:
> guess it is a matter of interpretation.
> I thought the discussion was that
> yes ftls are better.
> I did not see anything about including widget in FTL.
> guess I missed that.
> 
> 
> Jonathon -- Improov sent the following on 12/3/2007 5:36 PM:
>> Actually, this isn't going backwards. It's going forward.
>>
>> Some screens are best done in ftl. This was discussed countless times
>> before.
>>
>> In getting ftl screens to use field widgets, we reuse more of OFBiz's
>> widgets in more places. This will bring us closer to using more of widgets.
>>
>> Jonathon
>>
>> BJ Freeman wrote:
>>> seems your going backwards.
>>> remove the ftl and use screen widgets that include formwidgets.
>>> add a class (style) and use the css for aligning tables.
>>>
>>> Jonathon -- Improov sent the following on 12/2/2007 8:48 PM:
>>>> The problem I'm facing now is that form widgets always have the start
>>>> and end wrappers (<table cellspacing...> and </table). It is not
>>>> possible to mix fields from one form into another form done in ftl.
>>>>
>>>> Attributes skip-start and skip-end only remove the <form> wrapper.
>>>>
>>>> Getting form widgets to say skip-table could solve this problem, though
>>>> it's not intuitive to use form widgets as field widgets. Better to use
>>>> field widgets in screen widgets instead. However, this approach could be
>>>> a quick interim fix.
>>>>
>>>> Another problem is the colspan for <td>. Maybe we can make that
>>>> variable.
>>>>
>>>> Field widgets like <drop-down> are fantastic. It's a pity we can't use
>>>> them inside of creative displays written in ftl.
>>>>
>>>> Si Chen did some FreeMarker macros for these, I believe. But if we're
>>>> gonna strongly advocate widget usage, I think we need to fill that void
>>>> in screen widgets. Going the FreeMarker macros route would basically
>>>> rewrite much of what is already provided by field widgets.
>>>>
>>>> Maybe have a generic "group of fields" widget via <fields>?
>>>>
>>>> Jonathon
>>>>
>>>>
>>>>
>>>
>>
>>
>>
> 
> 

Re: Any plan to allow field widgets like inside ?

[BJ Freeman <bj...@free-man.net>]

guess it is a matter of interpretation.
I thought the discussion was that
yes ftls are better.
I did not see anything about including widget in FTL.
guess I missed that.


Jonathon -- Improov sent the following on 12/3/2007 5:36 PM:
> Actually, this isn't going backwards. It's going forward.
> 
> Some screens are best done in ftl. This was discussed countless times
> before.
> 
> In getting ftl screens to use field widgets, we reuse more of OFBiz's
> widgets in more places. This will bring us closer to using more of widgets.
> 
> Jonathon
> 
> BJ Freeman wrote:
>> seems your going backwards.
>> remove the ftl and use screen widgets that include formwidgets.
>> add a class (style) and use the css for aligning tables.
>>
>> Jonathon -- Improov sent the following on 12/2/2007 8:48 PM:
>>> The problem I'm facing now is that form widgets always have the start
>>> and end wrappers (<table cellspacing...> and </table). It is not
>>> possible to mix fields from one form into another form done in ftl.
>>>
>>> Attributes skip-start and skip-end only remove the <form> wrapper.
>>>
>>> Getting form widgets to say skip-table could solve this problem, though
>>> it's not intuitive to use form widgets as field widgets. Better to use
>>> field widgets in screen widgets instead. However, this approach could be
>>> a quick interim fix.
>>>
>>> Another problem is the colspan for <td>. Maybe we can make that
>>> variable.
>>>
>>> Field widgets like <drop-down> are fantastic. It's a pity we can't use
>>> them inside of creative displays written in ftl.
>>>
>>> Si Chen did some FreeMarker macros for these, I believe. But if we're
>>> gonna strongly advocate widget usage, I think we need to fill that void
>>> in screen widgets. Going the FreeMarker macros route would basically
>>> rewrite much of what is already provided by field widgets.
>>>
>>> Maybe have a generic "group of fields" widget via <fields>?
>>>
>>> Jonathon
>>>
>>>
>>>
>>
>>
> 
> 
> 
> 

Re: Any plan to allow field widgets like inside ?

[BJ Freeman <bj...@free-man.net>]

yes, what I meant is it was dependent on opentaps modifications.
not in the obiz trunk, yet.

skip@thedevers sent the following on 12/4/2007 11:33 AM:
> This is not opentaps code, it is MY code, but I did copy the
> screens.rennder() technique from Leon.
> 
> It is however done on an opentaps distribution.  I have not tried it on
> ofbiz raw, but the screen renderer is ofbiz code, so I dont think it would
> be hard to implement if it can't be done now.  (I know this because I got
> errors initially and looked at LOTS of stack traces).
> 
> Skip
> 
> -----Original Message-----
> From: BJ Freeman [mailto:bjfree@free-man.net]
> Sent: Tuesday, December 04, 2007 11:04 AM
> To: user@ofbiz.apache.org
> Subject: Re: Any plan to allow field widgets like <drop-down> inside
> <screen>?
> 
> 
> skip that is opentaps code, if I am not mistaken.
> does the ftl code in ofbiz trunk support this?
> 
> skip@thedevers sent the following on 12/4/2007 10:55 AM:
>> Yep, you can already do it,  check out the screens.render line
>>
>> #if collectionSummary?has_content>
>> <div class="screenlet-body">
>>   <table width="100%" border="0" cellspacing="5">
>>     <tr>
>>       <td width="50%">
>>
>>
> ${screens.render("component://ar/widget/opentaps/collections/screens/Collect
>> ionScreens.xml#collectionWorkArea")}
>>       </td>
>>       <td width="50%">
>>    	     <#if chartURL?has_content>
>>             <img src="${chartURL}" style="vertical-align:middle;
>> margin-left:35px"/>
>>          <#else>
>>             No chart Image
>>          </#if>
>>        </td>
>>     </tr>
>> </table>
>> </div>
>> <#else>
>>   ${uiLabelMap.PartyNoPartyFoundWithPartyId}:
>> ${parameters.partyId?if_exists}
>> </#if>
>>
>>
>>
>> -----Original Message-----
>> From: Jonathon -- Improov [mailto:jonw@improov.com]
>> Sent: Tuesday, December 04, 2007 1:02 AM
>> To: user@ofbiz.apache.org
>> Subject: Re: Any plan to allow field widgets like <drop-down> inside
>> <screen>?
>>
>>
>> Skip,
>>
>> Do you mean it can currently be done already? Didn't know this.
>>
>> Or you mean it's a good step forward?
>>
>> Right now, whenever widgets are inadequate, a common practice (maybe the
>> only feasible one) is to
>> jump right into FTL and forget about widgets.
>>
>> (But if you can do all-widget forms and all-ftl forms, they do mix. I
>> replied to your post about
>> the "screens as building blocks" thing.)
>>
>> The lack of widgets (like convenient <drop-down>) in FTL is possibly the
>> main motivation behind Si
>> Chen's (opentaps) route with FreeMarker macros. Was mine too, at one time.
> I
>> had a library of
>> macros (sold, privatized, again, sigh).
>>
>> Jonathon
>>
>> skip@thedevers wrote:
>>> Widgets in FTL is the only way currently to get some things done if you
>> want
>>> to use widgets.
>>>
>>> Skip
>>>
>>> -----Original Message-----
>>> From: Jonathon -- Improov [mailto:jonw@improov.com]
>>> Sent: Monday, December 03, 2007 5:36 PM
>>> To: user@ofbiz.apache.org
>>> Subject: Re: Any plan to allow field widgets like <drop-down> inside
>>> <screen>?
>>>
>>>
>>> Actually, this isn't going backwards. It's going forward.
>>>
>>> Some screens are best done in ftl. This was discussed countless times
>>> before.
>>>
>>> In getting ftl screens to use field widgets, we reuse more of OFBiz's
>>> widgets in more places. This
>>> will bring us closer to using more of widgets.
>>>
>>> Jonathon
>>>
>>> BJ Freeman wrote:
>>>> seems your going backwards.
>>>> remove the ftl and use screen widgets that include formwidgets.
>>>> add a class (style) and use the css for aligning tables.
>>>>
>>>> Jonathon -- Improov sent the following on 12/2/2007 8:48 PM:
>>>>> The problem I'm facing now is that form widgets always have the start
>>>>> and end wrappers (<table cellspacing...> and </table). It is not
>>>>> possible to mix fields from one form into another form done in ftl.
>>>>>
>>>>> Attributes skip-start and skip-end only remove the <form> wrapper.
>>>>>
>>>>> Getting form widgets to say skip-table could solve this problem, though
>>>>> it's not intuitive to use form widgets as field widgets. Better to use
>>>>> field widgets in screen widgets instead. However, this approach could
> be
>>>>> a quick interim fix.
>>>>>
>>>>> Another problem is the colspan for <td>. Maybe we can make that
>> variable.
>>>>> Field widgets like <drop-down> are fantastic. It's a pity we can't use
>>>>> them inside of creative displays written in ftl.
>>>>>
>>>>> Si Chen did some FreeMarker macros for these, I believe. But if we're
>>>>> gonna strongly advocate widget usage, I think we need to fill that void
>>>>> in screen widgets. Going the FreeMarker macros route would basically
>>>>> rewrite much of what is already provided by field widgets.
>>>>>
>>>>> Maybe have a generic "group of fields" widget via <fields>?
>>>>>
>>>>> Jonathon
>>>>>
>>>>>
>>>>>
>>>
>>
>>
>>
>>
> 
> 
> 
> 
> 

RE: Any plan to allow field widgets like inside ?

["skip@thedevers" <sk...@thedevers.org>]

This is not opentaps code, it is MY code, but I did copy the
screens.rennder() technique from Leon.

It is however done on an opentaps distribution.  I have not tried it on
ofbiz raw, but the screen renderer is ofbiz code, so I dont think it would
be hard to implement if it can't be done now.  (I know this because I got
errors initially and looked at LOTS of stack traces).

Skip

-----Original Message-----
From: BJ Freeman [mailto:bjfree@free-man.net]
Sent: Tuesday, December 04, 2007 11:04 AM
To: user@ofbiz.apache.org
Subject: Re: Any plan to allow field widgets like <drop-down> inside
<screen>?


skip that is opentaps code, if I am not mistaken.
does the ftl code in ofbiz trunk support this?

skip@thedevers sent the following on 12/4/2007 10:55 AM:
> Yep, you can already do it,  check out the screens.render line
>
> #if collectionSummary?has_content>
> <div class="screenlet-body">
>   <table width="100%" border="0" cellspacing="5">
>     <tr>
>       <td width="50%">
>
>
${screens.render("component://ar/widget/opentaps/collections/screens/Collect
> ionScreens.xml#collectionWorkArea")}
>       </td>
>       <td width="50%">
>    	     <#if chartURL?has_content>
>             <img src="${chartURL}" style="vertical-align:middle;
> margin-left:35px"/>
>          <#else>
>             No chart Image
>          </#if>
>        </td>
>     </tr>
> </table>
> </div>
> <#else>
>   ${uiLabelMap.PartyNoPartyFoundWithPartyId}:
> ${parameters.partyId?if_exists}
> </#if>
>
>
>
> -----Original Message-----
> From: Jonathon -- Improov [mailto:jonw@improov.com]
> Sent: Tuesday, December 04, 2007 1:02 AM
> To: user@ofbiz.apache.org
> Subject: Re: Any plan to allow field widgets like <drop-down> inside
> <screen>?
>
>
> Skip,
>
> Do you mean it can currently be done already? Didn't know this.
>
> Or you mean it's a good step forward?
>
> Right now, whenever widgets are inadequate, a common practice (maybe the
> only feasible one) is to
> jump right into FTL and forget about widgets.
>
> (But if you can do all-widget forms and all-ftl forms, they do mix. I
> replied to your post about
> the "screens as building blocks" thing.)
>
> The lack of widgets (like convenient <drop-down>) in FTL is possibly the
> main motivation behind Si
> Chen's (opentaps) route with FreeMarker macros. Was mine too, at one time.
I
> had a library of
> macros (sold, privatized, again, sigh).
>
> Jonathon
>
> skip@thedevers wrote:
>> Widgets in FTL is the only way currently to get some things done if you
> want
>> to use widgets.
>>
>> Skip
>>
>> -----Original Message-----
>> From: Jonathon -- Improov [mailto:jonw@improov.com]
>> Sent: Monday, December 03, 2007 5:36 PM
>> To: user@ofbiz.apache.org
>> Subject: Re: Any plan to allow field widgets like <drop-down> inside
>> <screen>?
>>
>>
>> Actually, this isn't going backwards. It's going forward.
>>
>> Some screens are best done in ftl. This was discussed countless times
>> before.
>>
>> In getting ftl screens to use field widgets, we reuse more of OFBiz's
>> widgets in more places. This
>> will bring us closer to using more of widgets.
>>
>> Jonathon
>>
>> BJ Freeman wrote:
>>> seems your going backwards.
>>> remove the ftl and use screen widgets that include formwidgets.
>>> add a class (style) and use the css for aligning tables.
>>>
>>> Jonathon -- Improov sent the following on 12/2/2007 8:48 PM:
>>>> The problem I'm facing now is that form widgets always have the start
>>>> and end wrappers (<table cellspacing...> and </table). It is not
>>>> possible to mix fields from one form into another form done in ftl.
>>>>
>>>> Attributes skip-start and skip-end only remove the <form> wrapper.
>>>>
>>>> Getting form widgets to say skip-table could solve this problem, though
>>>> it's not intuitive to use form widgets as field widgets. Better to use
>>>> field widgets in screen widgets instead. However, this approach could
be
>>>> a quick interim fix.
>>>>
>>>> Another problem is the colspan for <td>. Maybe we can make that
> variable.
>>>> Field widgets like <drop-down> are fantastic. It's a pity we can't use
>>>> them inside of creative displays written in ftl.
>>>>
>>>> Si Chen did some FreeMarker macros for these, I believe. But if we're
>>>> gonna strongly advocate widget usage, I think we need to fill that void
>>>> in screen widgets. Going the FreeMarker macros route would basically
>>>> rewrite much of what is already provided by field widgets.
>>>>
>>>> Maybe have a generic "group of fields" widget via <fields>?
>>>>
>>>> Jonathon
>>>>
>>>>
>>>>
>>
>>
>
>
>
>
>

Re: Any plan to allow field widgets like inside ?

[BJ Freeman <bj...@free-man.net>]

skip that is opentaps code, if I am not mistaken.
does the ftl code in ofbiz trunk support this?

skip@thedevers sent the following on 12/4/2007 10:55 AM:
> Yep, you can already do it,  check out the screens.render line
> 
> #if collectionSummary?has_content>
> <div class="screenlet-body">
>   <table width="100%" border="0" cellspacing="5">
>     <tr>
>       <td width="50%">
> 
> ${screens.render("component://ar/widget/opentaps/collections/screens/Collect
> ionScreens.xml#collectionWorkArea")}
>       </td>
>       <td width="50%">
>    	     <#if chartURL?has_content>
>             <img src="${chartURL}" style="vertical-align:middle;
> margin-left:35px"/>
>          <#else>
>             No chart Image
>          </#if>
>        </td>
>     </tr>
> </table>
> </div>
> <#else>
>   ${uiLabelMap.PartyNoPartyFoundWithPartyId}:
> ${parameters.partyId?if_exists}
> </#if>
> 
> 
> 
> -----Original Message-----
> From: Jonathon -- Improov [mailto:jonw@improov.com]
> Sent: Tuesday, December 04, 2007 1:02 AM
> To: user@ofbiz.apache.org
> Subject: Re: Any plan to allow field widgets like <drop-down> inside
> <screen>?
> 
> 
> Skip,
> 
> Do you mean it can currently be done already? Didn't know this.
> 
> Or you mean it's a good step forward?
> 
> Right now, whenever widgets are inadequate, a common practice (maybe the
> only feasible one) is to
> jump right into FTL and forget about widgets.
> 
> (But if you can do all-widget forms and all-ftl forms, they do mix. I
> replied to your post about
> the "screens as building blocks" thing.)
> 
> The lack of widgets (like convenient <drop-down>) in FTL is possibly the
> main motivation behind Si
> Chen's (opentaps) route with FreeMarker macros. Was mine too, at one time. I
> had a library of
> macros (sold, privatized, again, sigh).
> 
> Jonathon
> 
> skip@thedevers wrote:
>> Widgets in FTL is the only way currently to get some things done if you
> want
>> to use widgets.
>>
>> Skip
>>
>> -----Original Message-----
>> From: Jonathon -- Improov [mailto:jonw@improov.com]
>> Sent: Monday, December 03, 2007 5:36 PM
>> To: user@ofbiz.apache.org
>> Subject: Re: Any plan to allow field widgets like <drop-down> inside
>> <screen>?
>>
>>
>> Actually, this isn't going backwards. It's going forward.
>>
>> Some screens are best done in ftl. This was discussed countless times
>> before.
>>
>> In getting ftl screens to use field widgets, we reuse more of OFBiz's
>> widgets in more places. This
>> will bring us closer to using more of widgets.
>>
>> Jonathon
>>
>> BJ Freeman wrote:
>>> seems your going backwards.
>>> remove the ftl and use screen widgets that include formwidgets.
>>> add a class (style) and use the css for aligning tables.
>>>
>>> Jonathon -- Improov sent the following on 12/2/2007 8:48 PM:
>>>> The problem I'm facing now is that form widgets always have the start
>>>> and end wrappers (<table cellspacing...> and </table). It is not
>>>> possible to mix fields from one form into another form done in ftl.
>>>>
>>>> Attributes skip-start and skip-end only remove the <form> wrapper.
>>>>
>>>> Getting form widgets to say skip-table could solve this problem, though
>>>> it's not intuitive to use form widgets as field widgets. Better to use
>>>> field widgets in screen widgets instead. However, this approach could be
>>>> a quick interim fix.
>>>>
>>>> Another problem is the colspan for <td>. Maybe we can make that
> variable.
>>>> Field widgets like <drop-down> are fantastic. It's a pity we can't use
>>>> them inside of creative displays written in ftl.
>>>>
>>>> Si Chen did some FreeMarker macros for these, I believe. But if we're
>>>> gonna strongly advocate widget usage, I think we need to fill that void
>>>> in screen widgets. Going the FreeMarker macros route would basically
>>>> rewrite much of what is already provided by field widgets.
>>>>
>>>> Maybe have a generic "group of fields" widget via <fields>?
>>>>
>>>> Jonathon
>>>>
>>>>
>>>>
>>
>>
> 
> 
> 
> 
> 

Re: Any plan to allow field widgets like inside ?

[Jonathon -- Improov <jo...@improov.com>]

Oops. Sorry.

Jonathon

Jacques Le Roux wrote:
> This discussion sounds interesting and should be rather done on the dev list, suggesting...
> 
> Jacques
> 
> De : "Jonathon -- Improov" <jo...@improov.com>
>> Forms can be written in total widget or total FTL, not a combination. That's the problem.
>>
>> See the editcontactmech.ftl example I gave.
>>
>> Also, see the skip-start and skip-end attributes discussion I gave on element <form>. Note also 
>> the inability to remove the <table> wrapper for <form>.
>>
>> Jonathon
>>
>> BJ Freeman wrote:
>>> ignorant question.
>>> if you can include a screen and a screen can include a form.
>>> what am I missing.
>>>
>>> Jonathon -- Improov sent the following on 12/4/2007 9:49 PM:
>>>> Skip,
>>>>
>>>> Yes, I knew we can include screen widgets in FTL. I told you "screens as
>>>> building blocks", remember?
>>>>
>>>> Also, check out ${sections.render('section_name')}, by the way.
>>>>
>>>> My problem is that I can't add less than a screen in FTL.
>>>>
>>>> Consider that you have in FTL a HTML form. Somewhere inside that form,
>>>> you want to insert a <drop-down> widget. You can't, so you do what Si
>>>> Chen did, using FreeMarker macros.
>>>>
>>>> Why are we doing a HTML form in FTL? Because as discussed often before,
>>>> some UIs just need to be complex and pretty and requires FTL.
>>>>
>>>> Why am I trying to include <drop-down> widget into a HTML form in FTL?
>>>> Because it's more complex to use FTL <select>. Let me give a concrete
>>>> example. See ${component:party}/webapp/partymgr/party/editcontactmech.ftl .
>>>>
>>>> See lines:
>>>>
>>>>   <select name="stateProvinceGeoId">
>>>>    
>>>> <option>${(mechMap.postalAddress.stateProvinceGeoId)?if_exists}</option>
>>>>     <option></option>
>>>>     ${screens.render("component://common/widget/CommonScreens.xml#states")}
>>>>   </select>
>>>>
>>>> Looks simple enough?
>>>>
>>>> See screen widget ${component:common}/widget/CommonScreens.xml#states .
>>>> It points to another FTL file in
>>>> /framework/common/webcommon/includes/states.ftl . Look in that
>>>> states.ftl , and see how a non-trivial CommonWorkers class is used.
>>>>
>>>> If we can use widgets, it's just:
>>>>
>>>> <field name="geoId">
>>>>   <drop-down>
>>>>     <entity-options entity-name="Geo" description="${geoName}"
>>>> combine="or">
>>>>       <entity-constraint name="geoTypeId" value="STATE">
>>>>       <entity-constraint name="geoTypeId" value="PROVINCE">
>>>>       <entity-order-by field-name="geoName"/>
>>>>     </entity-options>
>>>>   </drop-down>
>>>> </field>
>>>>
>>>> Compare the above <field> to the alternative now. See the <select>
>>>> chunk, plus the <screen name="states"> chunk, plus the states.ftl, plus
>>>> the CommonWorkers.getStateList() chunk.
>>>>
>>>> Note note! The attribute "combine" in element <entity-options> does not
>>>> exist... yet. :) Currently, all <entity-constraint> elements are "ANDed"
>>>> together, not "ORed".
>>>>
>>>> Jonathon
>>>>
>>>> skip@thedevers wrote:
>>>>> Yep, you can already do it,  check out the screens.render line
>>>>>
>>>>> #if collectionSummary?has_content>
>>>>> <div class="screenlet-body">
>>>>>   <table width="100%" border="0" cellspacing="5">
>>>>>     <tr>
>>>>>       <td width="50%">
>>>>>
>>>>> ${screens.render("component://ar/widget/opentaps/collections/screens/Collect
>>>>>
>>>>> ionScreens.xml#collectionWorkArea")}
>>>>>       </td>
>>>>>       <td width="50%">
>>>>>             <#if chartURL?has_content>
>>>>>             <img src="${chartURL}" style="vertical-align:middle;
>>>>> margin-left:35px"/>
>>>>>          <#else>
>>>>>             No chart Image
>>>>>          </#if>
>>>>>        </td>
>>>>>     </tr>
>>>>> </table>
>>>>> </div>
>>>>> <#else>
>>>>>   ${uiLabelMap.PartyNoPartyFoundWithPartyId}:
>>>>> ${parameters.partyId?if_exists}
>>>>> </#if>
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Jonathon -- Improov [mailto:jonw@improov.com]
>>>>> Sent: Tuesday, December 04, 2007 1:02 AM
>>>>> To: user@ofbiz.apache.org
>>>>> Subject: Re: Any plan to allow field widgets like <drop-down> inside
>>>>> <screen>?
>>>>>
>>>>>
>>>>> Skip,
>>>>>
>>>>> Do you mean it can currently be done already? Didn't know this.
>>>>>
>>>>> Or you mean it's a good step forward?
>>>>>
>>>>> Right now, whenever widgets are inadequate, a common practice (maybe the
>>>>> only feasible one) is to
>>>>> jump right into FTL and forget about widgets.
>>>>>
>>>>> (But if you can do all-widget forms and all-ftl forms, they do mix. I
>>>>> replied to your post about
>>>>> the "screens as building blocks" thing.)
>>>>>
>>>>> The lack of widgets (like convenient <drop-down>) in FTL is possibly the
>>>>> main motivation behind Si
>>>>> Chen's (opentaps) route with FreeMarker macros. Was mine too, at one
>>>>> time. I
>>>>> had a library of
>>>>> macros (sold, privatized, again, sigh).
>>>>>
>>>>> Jonathon
>>>>>
>>>>> skip@thedevers wrote:
>>>>>> Widgets in FTL is the only way currently to get some things done if you
>>>>> want
>>>>>> to use widgets.
>>>>>>
>>>>>> Skip
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Jonathon -- Improov [mailto:jonw@improov.com]
>>>>>> Sent: Monday, December 03, 2007 5:36 PM
>>>>>> To: user@ofbiz.apache.org
>>>>>> Subject: Re: Any plan to allow field widgets like <drop-down> inside
>>>>>> <screen>?
>>>>>>
>>>>>>
>>>>>> Actually, this isn't going backwards. It's going forward.
>>>>>>
>>>>>> Some screens are best done in ftl. This was discussed countless times
>>>>>> before.
>>>>>>
>>>>>> In getting ftl screens to use field widgets, we reuse more of OFBiz's
>>>>>> widgets in more places. This
>>>>>> will bring us closer to using more of widgets.
>>>>>>
>>>>>> Jonathon
>>>>>>
>>>>>> BJ Freeman wrote:
>>>>>>> seems your going backwards.
>>>>>>> remove the ftl and use screen widgets that include formwidgets.
>>>>>>> add a class (style) and use the css for aligning tables.
>>>>>>>
>>>>>>> Jonathon -- Improov sent the following on 12/2/2007 8:48 PM:
>>>>>>>> The problem I'm facing now is that form widgets always have the start
>>>>>>>> and end wrappers (<table cellspacing...> and </table). It is not
>>>>>>>> possible to mix fields from one form into another form done in ftl.
>>>>>>>>
>>>>>>>> Attributes skip-start and skip-end only remove the <form> wrapper.
>>>>>>>>
>>>>>>>> Getting form widgets to say skip-table could solve this problem,
>>>>>>>> though
>>>>>>>> it's not intuitive to use form widgets as field widgets. Better to use
>>>>>>>> field widgets in screen widgets instead. However, this approach
>>>>>>>> could be
>>>>>>>> a quick interim fix.
>>>>>>>>
>>>>>>>> Another problem is the colspan for <td>. Maybe we can make that
>>>>> variable.
>>>>>>>> Field widgets like <drop-down> are fantastic. It's a pity we can't use
>>>>>>>> them inside of creative displays written in ftl.
>>>>>>>>
>>>>>>>> Si Chen did some FreeMarker macros for these, I believe. But if we're
>>>>>>>> gonna strongly advocate widget usage, I think we need to fill that
>>>>>>>> void
>>>>>>>> in screen widgets. Going the FreeMarker macros route would basically
>>>>>>>> rewrite much of what is already provided by field widgets.
>>>>>>>>
>>>>>>>> Maybe have a generic "group of fields" widget via <fields>?
>>>>>>>>
>>>>>>>> Jonathon
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>>>>
>>>
> 
> 

Re: Any plan to allow field widgets like inside ?

[Jacques Le Roux <ja...@les7arts.com>]

This discussion sounds interesting and should be rather done on the dev list, suggesting...

Jacques

De : "Jonathon -- Improov" <jo...@improov.com>
> Forms can be written in total widget or total FTL, not a combination. That's the problem.
> 
> See the editcontactmech.ftl example I gave.
> 
> Also, see the skip-start and skip-end attributes discussion I gave on element <form>. Note also 
> the inability to remove the <table> wrapper for <form>.
> 
> Jonathon
> 
> BJ Freeman wrote:
> > ignorant question.
> > if you can include a screen and a screen can include a form.
> > what am I missing.
> > 
> > Jonathon -- Improov sent the following on 12/4/2007 9:49 PM:
> >> Skip,
> >>
> >> Yes, I knew we can include screen widgets in FTL. I told you "screens as
> >> building blocks", remember?
> >>
> >> Also, check out ${sections.render('section_name')}, by the way.
> >>
> >> My problem is that I can't add less than a screen in FTL.
> >>
> >> Consider that you have in FTL a HTML form. Somewhere inside that form,
> >> you want to insert a <drop-down> widget. You can't, so you do what Si
> >> Chen did, using FreeMarker macros.
> >>
> >> Why are we doing a HTML form in FTL? Because as discussed often before,
> >> some UIs just need to be complex and pretty and requires FTL.
> >>
> >> Why am I trying to include <drop-down> widget into a HTML form in FTL?
> >> Because it's more complex to use FTL <select>. Let me give a concrete
> >> example. See ${component:party}/webapp/partymgr/party/editcontactmech.ftl .
> >>
> >> See lines:
> >>
> >>   <select name="stateProvinceGeoId">
> >>    
> >> <option>${(mechMap.postalAddress.stateProvinceGeoId)?if_exists}</option>
> >>     <option></option>
> >>     ${screens.render("component://common/widget/CommonScreens.xml#states")}
> >>   </select>
> >>
> >> Looks simple enough?
> >>
> >> See screen widget ${component:common}/widget/CommonScreens.xml#states .
> >> It points to another FTL file in
> >> /framework/common/webcommon/includes/states.ftl . Look in that
> >> states.ftl , and see how a non-trivial CommonWorkers class is used.
> >>
> >> If we can use widgets, it's just:
> >>
> >> <field name="geoId">
> >>   <drop-down>
> >>     <entity-options entity-name="Geo" description="${geoName}"
> >> combine="or">
> >>       <entity-constraint name="geoTypeId" value="STATE">
> >>       <entity-constraint name="geoTypeId" value="PROVINCE">
> >>       <entity-order-by field-name="geoName"/>
> >>     </entity-options>
> >>   </drop-down>
> >> </field>
> >>
> >> Compare the above <field> to the alternative now. See the <select>
> >> chunk, plus the <screen name="states"> chunk, plus the states.ftl, plus
> >> the CommonWorkers.getStateList() chunk.
> >>
> >> Note note! The attribute "combine" in element <entity-options> does not
> >> exist... yet. :) Currently, all <entity-constraint> elements are "ANDed"
> >> together, not "ORed".
> >>
> >> Jonathon
> >>
> >> skip@thedevers wrote:
> >>> Yep, you can already do it,  check out the screens.render line
> >>>
> >>> #if collectionSummary?has_content>
> >>> <div class="screenlet-body">
> >>>   <table width="100%" border="0" cellspacing="5">
> >>>     <tr>
> >>>       <td width="50%">
> >>>
> >>> ${screens.render("component://ar/widget/opentaps/collections/screens/Collect
> >>>
> >>> ionScreens.xml#collectionWorkArea")}
> >>>       </td>
> >>>       <td width="50%">
> >>>             <#if chartURL?has_content>
> >>>             <img src="${chartURL}" style="vertical-align:middle;
> >>> margin-left:35px"/>
> >>>          <#else>
> >>>             No chart Image
> >>>          </#if>
> >>>        </td>
> >>>     </tr>
> >>> </table>
> >>> </div>
> >>> <#else>
> >>>   ${uiLabelMap.PartyNoPartyFoundWithPartyId}:
> >>> ${parameters.partyId?if_exists}
> >>> </#if>
> >>>
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Jonathon -- Improov [mailto:jonw@improov.com]
> >>> Sent: Tuesday, December 04, 2007 1:02 AM
> >>> To: user@ofbiz.apache.org
> >>> Subject: Re: Any plan to allow field widgets like <drop-down> inside
> >>> <screen>?
> >>>
> >>>
> >>> Skip,
> >>>
> >>> Do you mean it can currently be done already? Didn't know this.
> >>>
> >>> Or you mean it's a good step forward?
> >>>
> >>> Right now, whenever widgets are inadequate, a common practice (maybe the
> >>> only feasible one) is to
> >>> jump right into FTL and forget about widgets.
> >>>
> >>> (But if you can do all-widget forms and all-ftl forms, they do mix. I
> >>> replied to your post about
> >>> the "screens as building blocks" thing.)
> >>>
> >>> The lack of widgets (like convenient <drop-down>) in FTL is possibly the
> >>> main motivation behind Si
> >>> Chen's (opentaps) route with FreeMarker macros. Was mine too, at one
> >>> time. I
> >>> had a library of
> >>> macros (sold, privatized, again, sigh).
> >>>
> >>> Jonathon
> >>>
> >>> skip@thedevers wrote:
> >>>> Widgets in FTL is the only way currently to get some things done if you
> >>> want
> >>>> to use widgets.
> >>>>
> >>>> Skip
> >>>>
> >>>> -----Original Message-----
> >>>> From: Jonathon -- Improov [mailto:jonw@improov.com]
> >>>> Sent: Monday, December 03, 2007 5:36 PM
> >>>> To: user@ofbiz.apache.org
> >>>> Subject: Re: Any plan to allow field widgets like <drop-down> inside
> >>>> <screen>?
> >>>>
> >>>>
> >>>> Actually, this isn't going backwards. It's going forward.
> >>>>
> >>>> Some screens are best done in ftl. This was discussed countless times
> >>>> before.
> >>>>
> >>>> In getting ftl screens to use field widgets, we reuse more of OFBiz's
> >>>> widgets in more places. This
> >>>> will bring us closer to using more of widgets.
> >>>>
> >>>> Jonathon
> >>>>
> >>>> BJ Freeman wrote:
> >>>>> seems your going backwards.
> >>>>> remove the ftl and use screen widgets that include formwidgets.
> >>>>> add a class (style) and use the css for aligning tables.
> >>>>>
> >>>>> Jonathon -- Improov sent the following on 12/2/2007 8:48 PM:
> >>>>>> The problem I'm facing now is that form widgets always have the start
> >>>>>> and end wrappers (<table cellspacing...> and </table). It is not
> >>>>>> possible to mix fields from one form into another form done in ftl.
> >>>>>>
> >>>>>> Attributes skip-start and skip-end only remove the <form> wrapper.
> >>>>>>
> >>>>>> Getting form widgets to say skip-table could solve this problem,
> >>>>>> though
> >>>>>> it's not intuitive to use form widgets as field widgets. Better to use
> >>>>>> field widgets in screen widgets instead. However, this approach
> >>>>>> could be
> >>>>>> a quick interim fix.
> >>>>>>
> >>>>>> Another problem is the colspan for <td>. Maybe we can make that
> >>> variable.
> >>>>>> Field widgets like <drop-down> are fantastic. It's a pity we can't use
> >>>>>> them inside of creative displays written in ftl.
> >>>>>>
> >>>>>> Si Chen did some FreeMarker macros for these, I believe. But if we're
> >>>>>> gonna strongly advocate widget usage, I think we need to fill that
> >>>>>> void
> >>>>>> in screen widgets. Going the FreeMarker macros route would basically
> >>>>>> rewrite much of what is already provided by field widgets.
> >>>>>>
> >>>>>> Maybe have a generic "group of fields" widget via <fields>?
> >>>>>>
> >>>>>> Jonathon
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >>
> > 
> > 
> 

Re: Any plan to allow field widgets like inside ?

[Jonathon -- Improov <jo...@improov.com>]

 > only use tables for "list" forms and just use divs for "single" forms

But how will we neatly arrange the form labels and form fields?

Currently, we use this (generated from form widget):

   <tr>
     <td>Form label:</td>
     <td>Form field</td>
   </tr>

In editcontactmech.ftl, the same strategy is used.

If we can have a new widget type, say <fields> (besides <screen> and <form>):

<fields name="stateProvinceGeo">
   <field name="stateProvinceGeoId">
     <drop-down>
       <entity-options entity-name="Geo" description="${geoName}" combine="or"
       key-field-name="geoId">
         <entity-constraint name="geoTypeId" value="STATE">
         <entity-constraint name="geoTypeId" value="PROVINCE">
         <entity-order-by field-name="geoName"/>
       </entity-options>
     </drop-down>
   </field>
</fields>

and in editcontactmech.ftl, we can do a:

${fields.render("stateProvinceGeo")}

That'll be nice. The render() method will point to the <fields> element above, I know that it's 
not completely correct coding form, sorry.

Jonathon

Jacopo Cappellato wrote:
> Jonathon -- Improov wrote:
>> Forms can be written in total widget or total FTL, not a combination. 
>> That's the problem.
>>
>> See the editcontactmech.ftl example I gave.
>>
>> Also, see the skip-start and skip-end attributes discussion I gave on 
>> element <form>. Note also the inability to remove the <table> wrapper 
>> for <form>.
>>
> 
> Speaking of this... it would be nice, in my opinion, to only use tables 
> for "list" forms and just use divs for "single" forms.
> This would also probably simply resolve (maybe) what Jonathon is trying 
> to accomplish.
> 
> Just my two cents,
> 
> Jacopo
> 
>> Jonathon
>>
>> BJ Freeman wrote:
>>> ignorant question.
>>> if you can include a screen and a screen can include a form.
>>> what am I missing.
>>>
>>> Jonathon -- Improov sent the following on 12/4/2007 9:49 PM:
>>>> Skip,
>>>>
>>>> Yes, I knew we can include screen widgets in FTL. I told you 
>>>> "screens as
>>>> building blocks", remember?
>>>>
>>>> Also, check out ${sections.render('section_name')}, by the way.
>>>>
>>>> My problem is that I can't add less than a screen in FTL.
>>>>
>>>> Consider that you have in FTL a HTML form. Somewhere inside that form,
>>>> you want to insert a <drop-down> widget. You can't, so you do what Si
>>>> Chen did, using FreeMarker macros.
>>>>
>>>> Why are we doing a HTML form in FTL? Because as discussed often before,
>>>> some UIs just need to be complex and pretty and requires FTL.
>>>>
>>>> Why am I trying to include <drop-down> widget into a HTML form in FTL?
>>>> Because it's more complex to use FTL <select>. Let me give a concrete
>>>> example. See 
>>>> ${component:party}/webapp/partymgr/party/editcontactmech.ftl .
>>>>
>>>> See lines:
>>>>
>>>>   <select name="stateProvinceGeoId">
>>>>    
>>>> <option>${(mechMap.postalAddress.stateProvinceGeoId)?if_exists}</option> 
>>>>
>>>>     <option></option>
>>>>     
>>>> ${screens.render("component://common/widget/CommonScreens.xml#states")}
>>>>   </select>
>>>>
>>>> Looks simple enough?
>>>>
>>>> See screen widget ${component:common}/widget/CommonScreens.xml#states .
>>>> It points to another FTL file in
>>>> /framework/common/webcommon/includes/states.ftl . Look in that
>>>> states.ftl , and see how a non-trivial CommonWorkers class is used.
>>>>
>>>> If we can use widgets, it's just:
>>>>
>>>> <field name="geoId">
>>>>   <drop-down>
>>>>     <entity-options entity-name="Geo" description="${geoName}"
>>>> combine="or">
>>>>       <entity-constraint name="geoTypeId" value="STATE">
>>>>       <entity-constraint name="geoTypeId" value="PROVINCE">
>>>>       <entity-order-by field-name="geoName"/>
>>>>     </entity-options>
>>>>   </drop-down>
>>>> </field>
>>>>
>>>> Compare the above <field> to the alternative now. See the <select>
>>>> chunk, plus the <screen name="states"> chunk, plus the states.ftl, plus
>>>> the CommonWorkers.getStateList() chunk.
>>>>
>>>> Note note! The attribute "combine" in element <entity-options> does not
>>>> exist... yet. :) Currently, all <entity-constraint> elements are 
>>>> "ANDed"
>>>> together, not "ORed".
>>>>
>>>> Jonathon
>>>>
>>>> skip@thedevers wrote:
>>>>> Yep, you can already do it,  check out the screens.render line
>>>>>
>>>>> #if collectionSummary?has_content>
>>>>> <div class="screenlet-body">
>>>>>   <table width="100%" border="0" cellspacing="5">
>>>>>     <tr>
>>>>>       <td width="50%">
>>>>>
>>>>> ${screens.render("component://ar/widget/opentaps/collections/screens/Collect 
>>>>>
>>>>>
>>>>> ionScreens.xml#collectionWorkArea")}
>>>>>       </td>
>>>>>       <td width="50%">
>>>>>             <#if chartURL?has_content>
>>>>>             <img src="${chartURL}" style="vertical-align:middle;
>>>>> margin-left:35px"/>
>>>>>          <#else>
>>>>>             No chart Image
>>>>>          </#if>
>>>>>        </td>
>>>>>     </tr>
>>>>> </table>
>>>>> </div>
>>>>> <#else>
>>>>>   ${uiLabelMap.PartyNoPartyFoundWithPartyId}:
>>>>> ${parameters.partyId?if_exists}
>>>>> </#if>
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Jonathon -- Improov [mailto:jonw@improov.com]
>>>>> Sent: Tuesday, December 04, 2007 1:02 AM
>>>>> To: user@ofbiz.apache.org
>>>>> Subject: Re: Any plan to allow field widgets like <drop-down> inside
>>>>> <screen>?
>>>>>
>>>>>
>>>>> Skip,
>>>>>
>>>>> Do you mean it can currently be done already? Didn't know this.
>>>>>
>>>>> Or you mean it's a good step forward?
>>>>>
>>>>> Right now, whenever widgets are inadequate, a common practice 
>>>>> (maybe the
>>>>> only feasible one) is to
>>>>> jump right into FTL and forget about widgets.
>>>>>
>>>>> (But if you can do all-widget forms and all-ftl forms, they do mix. I
>>>>> replied to your post about
>>>>> the "screens as building blocks" thing.)
>>>>>
>>>>> The lack of widgets (like convenient <drop-down>) in FTL is 
>>>>> possibly the
>>>>> main motivation behind Si
>>>>> Chen's (opentaps) route with FreeMarker macros. Was mine too, at one
>>>>> time. I
>>>>> had a library of
>>>>> macros (sold, privatized, again, sigh).
>>>>>
>>>>> Jonathon
>>>>>
>>>>> skip@thedevers wrote:
>>>>>> Widgets in FTL is the only way currently to get some things done 
>>>>>> if you
>>>>> want
>>>>>> to use widgets.
>>>>>>
>>>>>> Skip
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Jonathon -- Improov [mailto:jonw@improov.com]
>>>>>> Sent: Monday, December 03, 2007 5:36 PM
>>>>>> To: user@ofbiz.apache.org
>>>>>> Subject: Re: Any plan to allow field widgets like <drop-down> inside
>>>>>> <screen>?
>>>>>>
>>>>>>
>>>>>> Actually, this isn't going backwards. It's going forward.
>>>>>>
>>>>>> Some screens are best done in ftl. This was discussed countless times
>>>>>> before.
>>>>>>
>>>>>> In getting ftl screens to use field widgets, we reuse more of OFBiz's
>>>>>> widgets in more places. This
>>>>>> will bring us closer to using more of widgets.
>>>>>>
>>>>>> Jonathon
>>>>>>
>>>>>> BJ Freeman wrote:
>>>>>>> seems your going backwards.
>>>>>>> remove the ftl and use screen widgets that include formwidgets.
>>>>>>> add a class (style) and use the css for aligning tables.
>>>>>>>
>>>>>>> Jonathon -- Improov sent the following on 12/2/2007 8:48 PM:
>>>>>>>> The problem I'm facing now is that form widgets always have the 
>>>>>>>> start
>>>>>>>> and end wrappers (<table cellspacing...> and </table). It is not
>>>>>>>> possible to mix fields from one form into another form done in ftl.
>>>>>>>>
>>>>>>>> Attributes skip-start and skip-end only remove the <form> wrapper.
>>>>>>>>
>>>>>>>> Getting form widgets to say skip-table could solve this problem,
>>>>>>>> though
>>>>>>>> it's not intuitive to use form widgets as field widgets. Better 
>>>>>>>> to use
>>>>>>>> field widgets in screen widgets instead. However, this approach
>>>>>>>> could be
>>>>>>>> a quick interim fix.
>>>>>>>>
>>>>>>>> Another problem is the colspan for <td>. Maybe we can make that
>>>>> variable.
>>>>>>>> Field widgets like <drop-down> are fantastic. It's a pity we 
>>>>>>>> can't use
>>>>>>>> them inside of creative displays written in ftl.
>>>>>>>>
>>>>>>>> Si Chen did some FreeMarker macros for these, I believe. But if 
>>>>>>>> we're
>>>>>>>> gonna strongly advocate widget usage, I think we need to fill that
>>>>>>>> void
>>>>>>>> in screen widgets. Going the FreeMarker macros route would 
>>>>>>>> basically
>>>>>>>> rewrite much of what is already provided by field widgets.
>>>>>>>>
>>>>>>>> Maybe have a generic "group of fields" widget via <fields>?
>>>>>>>>
>>>>>>>> Jonathon
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
> 
> 

Re: Any plan to allow field widgets like inside ?

[Jacopo Cappellato <ti...@sastau.it>]

Jonathon -- Improov wrote:
> Forms can be written in total widget or total FTL, not a combination. 
> That's the problem.
> 
> See the editcontactmech.ftl example I gave.
> 
> Also, see the skip-start and skip-end attributes discussion I gave on 
> element <form>. Note also the inability to remove the <table> wrapper 
> for <form>.
> 

Speaking of this... it would be nice, in my opinion, to only use tables 
for "list" forms and just use divs for "single" forms.
This would also probably simply resolve (maybe) what Jonathon is trying 
to accomplish.

Just my two cents,

Jacopo

> Jonathon
> 
> BJ Freeman wrote:
>> ignorant question.
>> if you can include a screen and a screen can include a form.
>> what am I missing.
>>
>> Jonathon -- Improov sent the following on 12/4/2007 9:49 PM:
>>> Skip,
>>>
>>> Yes, I knew we can include screen widgets in FTL. I told you "screens as
>>> building blocks", remember?
>>>
>>> Also, check out ${sections.render('section_name')}, by the way.
>>>
>>> My problem is that I can't add less than a screen in FTL.
>>>
>>> Consider that you have in FTL a HTML form. Somewhere inside that form,
>>> you want to insert a <drop-down> widget. You can't, so you do what Si
>>> Chen did, using FreeMarker macros.
>>>
>>> Why are we doing a HTML form in FTL? Because as discussed often before,
>>> some UIs just need to be complex and pretty and requires FTL.
>>>
>>> Why am I trying to include <drop-down> widget into a HTML form in FTL?
>>> Because it's more complex to use FTL <select>. Let me give a concrete
>>> example. See 
>>> ${component:party}/webapp/partymgr/party/editcontactmech.ftl .
>>>
>>> See lines:
>>>
>>>   <select name="stateProvinceGeoId">
>>>    
>>> <option>${(mechMap.postalAddress.stateProvinceGeoId)?if_exists}</option>
>>>     <option></option>
>>>     
>>> ${screens.render("component://common/widget/CommonScreens.xml#states")}
>>>   </select>
>>>
>>> Looks simple enough?
>>>
>>> See screen widget ${component:common}/widget/CommonScreens.xml#states .
>>> It points to another FTL file in
>>> /framework/common/webcommon/includes/states.ftl . Look in that
>>> states.ftl , and see how a non-trivial CommonWorkers class is used.
>>>
>>> If we can use widgets, it's just:
>>>
>>> <field name="geoId">
>>>   <drop-down>
>>>     <entity-options entity-name="Geo" description="${geoName}"
>>> combine="or">
>>>       <entity-constraint name="geoTypeId" value="STATE">
>>>       <entity-constraint name="geoTypeId" value="PROVINCE">
>>>       <entity-order-by field-name="geoName"/>
>>>     </entity-options>
>>>   </drop-down>
>>> </field>
>>>
>>> Compare the above <field> to the alternative now. See the <select>
>>> chunk, plus the <screen name="states"> chunk, plus the states.ftl, plus
>>> the CommonWorkers.getStateList() chunk.
>>>
>>> Note note! The attribute "combine" in element <entity-options> does not
>>> exist... yet. :) Currently, all <entity-constraint> elements are "ANDed"
>>> together, not "ORed".
>>>
>>> Jonathon
>>>
>>> skip@thedevers wrote:
>>>> Yep, you can already do it,  check out the screens.render line
>>>>
>>>> #if collectionSummary?has_content>
>>>> <div class="screenlet-body">
>>>>   <table width="100%" border="0" cellspacing="5">
>>>>     <tr>
>>>>       <td width="50%">
>>>>
>>>> ${screens.render("component://ar/widget/opentaps/collections/screens/Collect 
>>>>
>>>>
>>>> ionScreens.xml#collectionWorkArea")}
>>>>       </td>
>>>>       <td width="50%">
>>>>             <#if chartURL?has_content>
>>>>             <img src="${chartURL}" style="vertical-align:middle;
>>>> margin-left:35px"/>
>>>>          <#else>
>>>>             No chart Image
>>>>          </#if>
>>>>        </td>
>>>>     </tr>
>>>> </table>
>>>> </div>
>>>> <#else>
>>>>   ${uiLabelMap.PartyNoPartyFoundWithPartyId}:
>>>> ${parameters.partyId?if_exists}
>>>> </#if>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Jonathon -- Improov [mailto:jonw@improov.com]
>>>> Sent: Tuesday, December 04, 2007 1:02 AM
>>>> To: user@ofbiz.apache.org
>>>> Subject: Re: Any plan to allow field widgets like <drop-down> inside
>>>> <screen>?
>>>>
>>>>
>>>> Skip,
>>>>
>>>> Do you mean it can currently be done already? Didn't know this.
>>>>
>>>> Or you mean it's a good step forward?
>>>>
>>>> Right now, whenever widgets are inadequate, a common practice (maybe 
>>>> the
>>>> only feasible one) is to
>>>> jump right into FTL and forget about widgets.
>>>>
>>>> (But if you can do all-widget forms and all-ftl forms, they do mix. I
>>>> replied to your post about
>>>> the "screens as building blocks" thing.)
>>>>
>>>> The lack of widgets (like convenient <drop-down>) in FTL is possibly 
>>>> the
>>>> main motivation behind Si
>>>> Chen's (opentaps) route with FreeMarker macros. Was mine too, at one
>>>> time. I
>>>> had a library of
>>>> macros (sold, privatized, again, sigh).
>>>>
>>>> Jonathon
>>>>
>>>> skip@thedevers wrote:
>>>>> Widgets in FTL is the only way currently to get some things done if 
>>>>> you
>>>> want
>>>>> to use widgets.
>>>>>
>>>>> Skip
>>>>>
>>>>> -----Original Message-----
>>>>> From: Jonathon -- Improov [mailto:jonw@improov.com]
>>>>> Sent: Monday, December 03, 2007 5:36 PM
>>>>> To: user@ofbiz.apache.org
>>>>> Subject: Re: Any plan to allow field widgets like <drop-down> inside
>>>>> <screen>?
>>>>>
>>>>>
>>>>> Actually, this isn't going backwards. It's going forward.
>>>>>
>>>>> Some screens are best done in ftl. This was discussed countless times
>>>>> before.
>>>>>
>>>>> In getting ftl screens to use field widgets, we reuse more of OFBiz's
>>>>> widgets in more places. This
>>>>> will bring us closer to using more of widgets.
>>>>>
>>>>> Jonathon
>>>>>
>>>>> BJ Freeman wrote:
>>>>>> seems your going backwards.
>>>>>> remove the ftl and use screen widgets that include formwidgets.
>>>>>> add a class (style) and use the css for aligning tables.
>>>>>>
>>>>>> Jonathon -- Improov sent the following on 12/2/2007 8:48 PM:
>>>>>>> The problem I'm facing now is that form widgets always have the 
>>>>>>> start
>>>>>>> and end wrappers (<table cellspacing...> and </table). It is not
>>>>>>> possible to mix fields from one form into another form done in ftl.
>>>>>>>
>>>>>>> Attributes skip-start and skip-end only remove the <form> wrapper.
>>>>>>>
>>>>>>> Getting form widgets to say skip-table could solve this problem,
>>>>>>> though
>>>>>>> it's not intuitive to use form widgets as field widgets. Better 
>>>>>>> to use
>>>>>>> field widgets in screen widgets instead. However, this approach
>>>>>>> could be
>>>>>>> a quick interim fix.
>>>>>>>
>>>>>>> Another problem is the colspan for <td>. Maybe we can make that
>>>> variable.
>>>>>>> Field widgets like <drop-down> are fantastic. It's a pity we 
>>>>>>> can't use
>>>>>>> them inside of creative displays written in ftl.
>>>>>>>
>>>>>>> Si Chen did some FreeMarker macros for these, I believe. But if 
>>>>>>> we're
>>>>>>> gonna strongly advocate widget usage, I think we need to fill that
>>>>>>> void
>>>>>>> in screen widgets. Going the FreeMarker macros route would basically
>>>>>>> rewrite much of what is already provided by field widgets.
>>>>>>>
>>>>>>> Maybe have a generic "group of fields" widget via <fields>?
>>>>>>>
>>>>>>> Jonathon
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>

Re: Any plan to allow field widgets like inside ?

[Jonathon -- Improov <jo...@improov.com>]

Forms can be written in total widget or total FTL, not a combination. That's the problem.

See the editcontactmech.ftl example I gave.

Also, see the skip-start and skip-end attributes discussion I gave on element <form>. Note also 
the inability to remove the <table> wrapper for <form>.

Jonathon

BJ Freeman wrote:
> ignorant question.
> if you can include a screen and a screen can include a form.
> what am I missing.
> 
> Jonathon -- Improov sent the following on 12/4/2007 9:49 PM:
>> Skip,
>>
>> Yes, I knew we can include screen widgets in FTL. I told you "screens as
>> building blocks", remember?
>>
>> Also, check out ${sections.render('section_name')}, by the way.
>>
>> My problem is that I can't add less than a screen in FTL.
>>
>> Consider that you have in FTL a HTML form. Somewhere inside that form,
>> you want to insert a <drop-down> widget. You can't, so you do what Si
>> Chen did, using FreeMarker macros.
>>
>> Why are we doing a HTML form in FTL? Because as discussed often before,
>> some UIs just need to be complex and pretty and requires FTL.
>>
>> Why am I trying to include <drop-down> widget into a HTML form in FTL?
>> Because it's more complex to use FTL <select>. Let me give a concrete
>> example. See ${component:party}/webapp/partymgr/party/editcontactmech.ftl .
>>
>> See lines:
>>
>>   <select name="stateProvinceGeoId">
>>    
>> <option>${(mechMap.postalAddress.stateProvinceGeoId)?if_exists}</option>
>>     <option></option>
>>     ${screens.render("component://common/widget/CommonScreens.xml#states")}
>>   </select>
>>
>> Looks simple enough?
>>
>> See screen widget ${component:common}/widget/CommonScreens.xml#states .
>> It points to another FTL file in
>> /framework/common/webcommon/includes/states.ftl . Look in that
>> states.ftl , and see how a non-trivial CommonWorkers class is used.
>>
>> If we can use widgets, it's just:
>>
>> <field name="geoId">
>>   <drop-down>
>>     <entity-options entity-name="Geo" description="${geoName}"
>> combine="or">
>>       <entity-constraint name="geoTypeId" value="STATE">
>>       <entity-constraint name="geoTypeId" value="PROVINCE">
>>       <entity-order-by field-name="geoName"/>
>>     </entity-options>
>>   </drop-down>
>> </field>
>>
>> Compare the above <field> to the alternative now. See the <select>
>> chunk, plus the <screen name="states"> chunk, plus the states.ftl, plus
>> the CommonWorkers.getStateList() chunk.
>>
>> Note note! The attribute "combine" in element <entity-options> does not
>> exist... yet. :) Currently, all <entity-constraint> elements are "ANDed"
>> together, not "ORed".
>>
>> Jonathon
>>
>> skip@thedevers wrote:
>>> Yep, you can already do it,  check out the screens.render line
>>>
>>> #if collectionSummary?has_content>
>>> <div class="screenlet-body">
>>>   <table width="100%" border="0" cellspacing="5">
>>>     <tr>
>>>       <td width="50%">
>>>
>>> ${screens.render("component://ar/widget/opentaps/collections/screens/Collect
>>>
>>> ionScreens.xml#collectionWorkArea")}
>>>       </td>
>>>       <td width="50%">
>>>             <#if chartURL?has_content>
>>>             <img src="${chartURL}" style="vertical-align:middle;
>>> margin-left:35px"/>
>>>          <#else>
>>>             No chart Image
>>>          </#if>
>>>        </td>
>>>     </tr>
>>> </table>
>>> </div>
>>> <#else>
>>>   ${uiLabelMap.PartyNoPartyFoundWithPartyId}:
>>> ${parameters.partyId?if_exists}
>>> </#if>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Jonathon -- Improov [mailto:jonw@improov.com]
>>> Sent: Tuesday, December 04, 2007 1:02 AM
>>> To: user@ofbiz.apache.org
>>> Subject: Re: Any plan to allow field widgets like <drop-down> inside
>>> <screen>?
>>>
>>>
>>> Skip,
>>>
>>> Do you mean it can currently be done already? Didn't know this.
>>>
>>> Or you mean it's a good step forward?
>>>
>>> Right now, whenever widgets are inadequate, a common practice (maybe the
>>> only feasible one) is to
>>> jump right into FTL and forget about widgets.
>>>
>>> (But if you can do all-widget forms and all-ftl forms, they do mix. I
>>> replied to your post about
>>> the "screens as building blocks" thing.)
>>>
>>> The lack of widgets (like convenient <drop-down>) in FTL is possibly the
>>> main motivation behind Si
>>> Chen's (opentaps) route with FreeMarker macros. Was mine too, at one
>>> time. I
>>> had a library of
>>> macros (sold, privatized, again, sigh).
>>>
>>> Jonathon
>>>
>>> skip@thedevers wrote:
>>>> Widgets in FTL is the only way currently to get some things done if you
>>> want
>>>> to use widgets.
>>>>
>>>> Skip
>>>>
>>>> -----Original Message-----
>>>> From: Jonathon -- Improov [mailto:jonw@improov.com]
>>>> Sent: Monday, December 03, 2007 5:36 PM
>>>> To: user@ofbiz.apache.org
>>>> Subject: Re: Any plan to allow field widgets like <drop-down> inside
>>>> <screen>?
>>>>
>>>>
>>>> Actually, this isn't going backwards. It's going forward.
>>>>
>>>> Some screens are best done in ftl. This was discussed countless times
>>>> before.
>>>>
>>>> In getting ftl screens to use field widgets, we reuse more of OFBiz's
>>>> widgets in more places. This
>>>> will bring us closer to using more of widgets.
>>>>
>>>> Jonathon
>>>>
>>>> BJ Freeman wrote:
>>>>> seems your going backwards.
>>>>> remove the ftl and use screen widgets that include formwidgets.
>>>>> add a class (style) and use the css for aligning tables.
>>>>>
>>>>> Jonathon -- Improov sent the following on 12/2/2007 8:48 PM:
>>>>>> The problem I'm facing now is that form widgets always have the start
>>>>>> and end wrappers (<table cellspacing...> and </table). It is not
>>>>>> possible to mix fields from one form into another form done in ftl.
>>>>>>
>>>>>> Attributes skip-start and skip-end only remove the <form> wrapper.
>>>>>>
>>>>>> Getting form widgets to say skip-table could solve this problem,
>>>>>> though
>>>>>> it's not intuitive to use form widgets as field widgets. Better to use
>>>>>> field widgets in screen widgets instead. However, this approach
>>>>>> could be
>>>>>> a quick interim fix.
>>>>>>
>>>>>> Another problem is the colspan for <td>. Maybe we can make that
>>> variable.
>>>>>> Field widgets like <drop-down> are fantastic. It's a pity we can't use
>>>>>> them inside of creative displays written in ftl.
>>>>>>
>>>>>> Si Chen did some FreeMarker macros for these, I believe. But if we're
>>>>>> gonna strongly advocate widget usage, I think we need to fill that
>>>>>> void
>>>>>> in screen widgets. Going the FreeMarker macros route would basically
>>>>>> rewrite much of what is already provided by field widgets.
>>>>>>
>>>>>> Maybe have a generic "group of fields" widget via <fields>?
>>>>>>
>>>>>> Jonathon
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>>
>>
>>
>>
> 
> 

Re: Any plan to allow field widgets like inside ?

[BJ Freeman <bj...@free-man.net>]

ignorant question.
if you can include a screen and a screen can include a form.
what am I missing.

Jonathon -- Improov sent the following on 12/4/2007 9:49 PM:
> Skip,
> 
> Yes, I knew we can include screen widgets in FTL. I told you "screens as
> building blocks", remember?
> 
> Also, check out ${sections.render('section_name')}, by the way.
> 
> My problem is that I can't add less than a screen in FTL.
> 
> Consider that you have in FTL a HTML form. Somewhere inside that form,
> you want to insert a <drop-down> widget. You can't, so you do what Si
> Chen did, using FreeMarker macros.
> 
> Why are we doing a HTML form in FTL? Because as discussed often before,
> some UIs just need to be complex and pretty and requires FTL.
> 
> Why am I trying to include <drop-down> widget into a HTML form in FTL?
> Because it's more complex to use FTL <select>. Let me give a concrete
> example. See ${component:party}/webapp/partymgr/party/editcontactmech.ftl .
> 
> See lines:
> 
>   <select name="stateProvinceGeoId">
>    
> <option>${(mechMap.postalAddress.stateProvinceGeoId)?if_exists}</option>
>     <option></option>
>     ${screens.render("component://common/widget/CommonScreens.xml#states")}
>   </select>
> 
> Looks simple enough?
> 
> See screen widget ${component:common}/widget/CommonScreens.xml#states .
> It points to another FTL file in
> /framework/common/webcommon/includes/states.ftl . Look in that
> states.ftl , and see how a non-trivial CommonWorkers class is used.
> 
> If we can use widgets, it's just:
> 
> <field name="geoId">
>   <drop-down>
>     <entity-options entity-name="Geo" description="${geoName}"
> combine="or">
>       <entity-constraint name="geoTypeId" value="STATE">
>       <entity-constraint name="geoTypeId" value="PROVINCE">
>       <entity-order-by field-name="geoName"/>
>     </entity-options>
>   </drop-down>
> </field>
> 
> Compare the above <field> to the alternative now. See the <select>
> chunk, plus the <screen name="states"> chunk, plus the states.ftl, plus
> the CommonWorkers.getStateList() chunk.
> 
> Note note! The attribute "combine" in element <entity-options> does not
> exist... yet. :) Currently, all <entity-constraint> elements are "ANDed"
> together, not "ORed".
> 
> Jonathon
> 
> skip@thedevers wrote:
>> Yep, you can already do it,  check out the screens.render line
>>
>> #if collectionSummary?has_content>
>> <div class="screenlet-body">
>>   <table width="100%" border="0" cellspacing="5">
>>     <tr>
>>       <td width="50%">
>>
>> ${screens.render("component://ar/widget/opentaps/collections/screens/Collect
>>
>> ionScreens.xml#collectionWorkArea")}
>>       </td>
>>       <td width="50%">
>>             <#if chartURL?has_content>
>>             <img src="${chartURL}" style="vertical-align:middle;
>> margin-left:35px"/>
>>          <#else>
>>             No chart Image
>>          </#if>
>>        </td>
>>     </tr>
>> </table>
>> </div>
>> <#else>
>>   ${uiLabelMap.PartyNoPartyFoundWithPartyId}:
>> ${parameters.partyId?if_exists}
>> </#if>
>>
>>
>>
>> -----Original Message-----
>> From: Jonathon -- Improov [mailto:jonw@improov.com]
>> Sent: Tuesday, December 04, 2007 1:02 AM
>> To: user@ofbiz.apache.org
>> Subject: Re: Any plan to allow field widgets like <drop-down> inside
>> <screen>?
>>
>>
>> Skip,
>>
>> Do you mean it can currently be done already? Didn't know this.
>>
>> Or you mean it's a good step forward?
>>
>> Right now, whenever widgets are inadequate, a common practice (maybe the
>> only feasible one) is to
>> jump right into FTL and forget about widgets.
>>
>> (But if you can do all-widget forms and all-ftl forms, they do mix. I
>> replied to your post about
>> the "screens as building blocks" thing.)
>>
>> The lack of widgets (like convenient <drop-down>) in FTL is possibly the
>> main motivation behind Si
>> Chen's (opentaps) route with FreeMarker macros. Was mine too, at one
>> time. I
>> had a library of
>> macros (sold, privatized, again, sigh).
>>
>> Jonathon
>>
>> skip@thedevers wrote:
>>> Widgets in FTL is the only way currently to get some things done if you
>> want
>>> to use widgets.
>>>
>>> Skip
>>>
>>> -----Original Message-----
>>> From: Jonathon -- Improov [mailto:jonw@improov.com]
>>> Sent: Monday, December 03, 2007 5:36 PM
>>> To: user@ofbiz.apache.org
>>> Subject: Re: Any plan to allow field widgets like <drop-down> inside
>>> <screen>?
>>>
>>>
>>> Actually, this isn't going backwards. It's going forward.
>>>
>>> Some screens are best done in ftl. This was discussed countless times
>>> before.
>>>
>>> In getting ftl screens to use field widgets, we reuse more of OFBiz's
>>> widgets in more places. This
>>> will bring us closer to using more of widgets.
>>>
>>> Jonathon
>>>
>>> BJ Freeman wrote:
>>>> seems your going backwards.
>>>> remove the ftl and use screen widgets that include formwidgets.
>>>> add a class (style) and use the css for aligning tables.
>>>>
>>>> Jonathon -- Improov sent the following on 12/2/2007 8:48 PM:
>>>>> The problem I'm facing now is that form widgets always have the start
>>>>> and end wrappers (<table cellspacing...> and </table). It is not
>>>>> possible to mix fields from one form into another form done in ftl.
>>>>>
>>>>> Attributes skip-start and skip-end only remove the <form> wrapper.
>>>>>
>>>>> Getting form widgets to say skip-table could solve this problem,
>>>>> though
>>>>> it's not intuitive to use form widgets as field widgets. Better to use
>>>>> field widgets in screen widgets instead. However, this approach
>>>>> could be
>>>>> a quick interim fix.
>>>>>
>>>>> Another problem is the colspan for <td>. Maybe we can make that
>> variable.
>>>>> Field widgets like <drop-down> are fantastic. It's a pity we can't use
>>>>> them inside of creative displays written in ftl.
>>>>>
>>>>> Si Chen did some FreeMarker macros for these, I believe. But if we're
>>>>> gonna strongly advocate widget usage, I think we need to fill that
>>>>> void
>>>>> in screen widgets. Going the FreeMarker macros route would basically
>>>>> rewrite much of what is already provided by field widgets.
>>>>>
>>>>> Maybe have a generic "group of fields" widget via <fields>?
>>>>>
>>>>> Jonathon
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>>
>>
> 
> 
> 
> 

Re: Any plan to allow field widgets like inside ?

[Jacopo Cappellato <ti...@sastau.it>]

Jonathon,

I agree that this would be a nice feature to have.

Jacopo

Jonathon -- Improov wrote:
> Sorry, it should be this:
> 
> <field name="stateProvinceGeoId">
>   <drop-down>
>     <entity-options entity-name="Geo" description="${geoName}" combine="or"
>     key-field-name="geoId">
>       <entity-constraint name="geoTypeId" value="STATE">
>       <entity-constraint name="geoTypeId" value="PROVINCE">
>       <entity-order-by field-name="geoName"/>
>     </entity-options>
>   </drop-down>
> </field>
> 
> Jonathon
> 
> Jonathon -- Improov wrote:
>> Skip,
>>
>> Yes, I knew we can include screen widgets in FTL. I told you "screens 
>> as building blocks", remember?
>>
>> Also, check out ${sections.render('section_name')}, by the way.
>>
>> My problem is that I can't add less than a screen in FTL.
>>
>> Consider that you have in FTL a HTML form. Somewhere inside that form, 
>> you want to insert a <drop-down> widget. You can't, so you do what Si 
>> Chen did, using FreeMarker macros.
>>
>> Why are we doing a HTML form in FTL? Because as discussed often 
>> before, some UIs just need to be complex and pretty and requires FTL.
>>
>> Why am I trying to include <drop-down> widget into a HTML form in FTL? 
>> Because it's more complex to use FTL <select>. Let me give a concrete 
>> example. See 
>> ${component:party}/webapp/partymgr/party/editcontactmech.ftl .
>>
>> See lines:
>>
>>   <select name="stateProvinceGeoId">
>>     
>> <option>${(mechMap.postalAddress.stateProvinceGeoId)?if_exists}</option>
>>     <option></option>
>>     
>> ${screens.render("component://common/widget/CommonScreens.xml#states")}
>>   </select>
>>
>> Looks simple enough?
>>
>> See screen widget ${component:common}/widget/CommonScreens.xml#states 
>> . It points to another FTL file in 
>> /framework/common/webcommon/includes/states.ftl . Look in that 
>> states.ftl , and see how a non-trivial CommonWorkers class is used.
>>
>> If we can use widgets, it's just:
>>
>> <field name="geoId">
>>   <drop-down>
>>     <entity-options entity-name="Geo" description="${geoName}" 
>> combine="or">
>>       <entity-constraint name="geoTypeId" value="STATE">
>>       <entity-constraint name="geoTypeId" value="PROVINCE">
>>       <entity-order-by field-name="geoName"/>
>>     </entity-options>
>>   </drop-down>
>> </field>
>>
>> Compare the above <field> to the alternative now. See the <select> 
>> chunk, plus the <screen name="states"> chunk, plus the states.ftl, 
>> plus the CommonWorkers.getStateList() chunk.
>>
>> Note note! The attribute "combine" in element <entity-options> does 
>> not exist... yet. :) Currently, all <entity-constraint> elements are 
>> "ANDed" together, not "ORed".
>>
>> Jonathon
>>
>> skip@thedevers wrote:
>>> Yep, you can already do it,  check out the screens.render line
>>>
>>> #if collectionSummary?has_content>
>>> <div class="screenlet-body">
>>>   <table width="100%" border="0" cellspacing="5">
>>>     <tr>
>>>       <td width="50%">
>>>
>>> ${screens.render("component://ar/widget/opentaps/collections/screens/Collect 
>>>
>>> ionScreens.xml#collectionWorkArea")}
>>>       </td>
>>>       <td width="50%">
>>>             <#if chartURL?has_content>
>>>             <img src="${chartURL}" style="vertical-align:middle;
>>> margin-left:35px"/>
>>>          <#else>
>>>             No chart Image
>>>          </#if>
>>>        </td>
>>>     </tr>
>>> </table>
>>> </div>
>>> <#else>
>>>   ${uiLabelMap.PartyNoPartyFoundWithPartyId}:
>>> ${parameters.partyId?if_exists}
>>> </#if>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Jonathon -- Improov [mailto:jonw@improov.com]
>>> Sent: Tuesday, December 04, 2007 1:02 AM
>>> To: user@ofbiz.apache.org
>>> Subject: Re: Any plan to allow field widgets like <drop-down> inside
>>> <screen>?
>>>
>>>
>>> Skip,
>>>
>>> Do you mean it can currently be done already? Didn't know this.
>>>
>>> Or you mean it's a good step forward?
>>>
>>> Right now, whenever widgets are inadequate, a common practice (maybe the
>>> only feasible one) is to
>>> jump right into FTL and forget about widgets.
>>>
>>> (But if you can do all-widget forms and all-ftl forms, they do mix. I
>>> replied to your post about
>>> the "screens as building blocks" thing.)
>>>
>>> The lack of widgets (like convenient <drop-down>) in FTL is possibly the
>>> main motivation behind Si
>>> Chen's (opentaps) route with FreeMarker macros. Was mine too, at one 
>>> time. I
>>> had a library of
>>> macros (sold, privatized, again, sigh).
>>>
>>> Jonathon
>>>
>>> skip@thedevers wrote:
>>>> Widgets in FTL is the only way currently to get some things done if you
>>> want
>>>> to use widgets.
>>>>
>>>> Skip
>>>>
>>>> -----Original Message-----
>>>> From: Jonathon -- Improov [mailto:jonw@improov.com]
>>>> Sent: Monday, December 03, 2007 5:36 PM
>>>> To: user@ofbiz.apache.org
>>>> Subject: Re: Any plan to allow field widgets like <drop-down> inside
>>>> <screen>?
>>>>
>>>>
>>>> Actually, this isn't going backwards. It's going forward.
>>>>
>>>> Some screens are best done in ftl. This was discussed countless times
>>>> before.
>>>>
>>>> In getting ftl screens to use field widgets, we reuse more of OFBiz's
>>>> widgets in more places. This
>>>> will bring us closer to using more of widgets.
>>>>
>>>> Jonathon
>>>>
>>>> BJ Freeman wrote:
>>>>> seems your going backwards.
>>>>> remove the ftl and use screen widgets that include formwidgets.
>>>>> add a class (style) and use the css for aligning tables.
>>>>>
>>>>> Jonathon -- Improov sent the following on 12/2/2007 8:48 PM:
>>>>>> The problem I'm facing now is that form widgets always have the start
>>>>>> and end wrappers (<table cellspacing...> and </table). It is not
>>>>>> possible to mix fields from one form into another form done in ftl.
>>>>>>
>>>>>> Attributes skip-start and skip-end only remove the <form> wrapper.
>>>>>>
>>>>>> Getting form widgets to say skip-table could solve this problem, 
>>>>>> though
>>>>>> it's not intuitive to use form widgets as field widgets. Better to 
>>>>>> use
>>>>>> field widgets in screen widgets instead. However, this approach 
>>>>>> could be
>>>>>> a quick interim fix.
>>>>>>
>>>>>> Another problem is the colspan for <td>. Maybe we can make that
>>> variable.
>>>>>> Field widgets like <drop-down> are fantastic. It's a pity we can't 
>>>>>> use
>>>>>> them inside of creative displays written in ftl.
>>>>>>
>>>>>> Si Chen did some FreeMarker macros for these, I believe. But if we're
>>>>>> gonna strongly advocate widget usage, I think we need to fill that 
>>>>>> void
>>>>>> in screen widgets. Going the FreeMarker macros route would basically
>>>>>> rewrite much of what is already provided by field widgets.
>>>>>>
>>>>>> Maybe have a generic "group of fields" widget via <fields>?
>>>>>>
>>>>>> Jonathon
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>

Re: Any plan to allow field widgets like inside ?

[Jonathon -- Improov <jo...@improov.com>]

Sorry, it should be this:

<field name="stateProvinceGeoId">
   <drop-down>
     <entity-options entity-name="Geo" description="${geoName}" combine="or"
     key-field-name="geoId">
       <entity-constraint name="geoTypeId" value="STATE">
       <entity-constraint name="geoTypeId" value="PROVINCE">
       <entity-order-by field-name="geoName"/>
     </entity-options>
   </drop-down>
</field>

Jonathon

Jonathon -- Improov wrote:
> Skip,
> 
> Yes, I knew we can include screen widgets in FTL. I told you "screens as 
> building blocks", remember?
> 
> Also, check out ${sections.render('section_name')}, by the way.
> 
> My problem is that I can't add less than a screen in FTL.
> 
> Consider that you have in FTL a HTML form. Somewhere inside that form, 
> you want to insert a <drop-down> widget. You can't, so you do what Si 
> Chen did, using FreeMarker macros.
> 
> Why are we doing a HTML form in FTL? Because as discussed often before, 
> some UIs just need to be complex and pretty and requires FTL.
> 
> Why am I trying to include <drop-down> widget into a HTML form in FTL? 
> Because it's more complex to use FTL <select>. Let me give a concrete 
> example. See ${component:party}/webapp/partymgr/party/editcontactmech.ftl .
> 
> See lines:
> 
>   <select name="stateProvinceGeoId">
>     
> <option>${(mechMap.postalAddress.stateProvinceGeoId)?if_exists}</option>
>     <option></option>
>     ${screens.render("component://common/widget/CommonScreens.xml#states")}
>   </select>
> 
> Looks simple enough?
> 
> See screen widget ${component:common}/widget/CommonScreens.xml#states . 
> It points to another FTL file in 
> /framework/common/webcommon/includes/states.ftl . Look in that 
> states.ftl , and see how a non-trivial CommonWorkers class is used.
> 
> If we can use widgets, it's just:
> 
> <field name="geoId">
>   <drop-down>
>     <entity-options entity-name="Geo" description="${geoName}" 
> combine="or">
>       <entity-constraint name="geoTypeId" value="STATE">
>       <entity-constraint name="geoTypeId" value="PROVINCE">
>       <entity-order-by field-name="geoName"/>
>     </entity-options>
>   </drop-down>
> </field>
> 
> Compare the above <field> to the alternative now. See the <select> 
> chunk, plus the <screen name="states"> chunk, plus the states.ftl, plus 
> the CommonWorkers.getStateList() chunk.
> 
> Note note! The attribute "combine" in element <entity-options> does not 
> exist... yet. :) Currently, all <entity-constraint> elements are "ANDed" 
> together, not "ORed".
> 
> Jonathon
> 
> skip@thedevers wrote:
>> Yep, you can already do it,  check out the screens.render line
>>
>> #if collectionSummary?has_content>
>> <div class="screenlet-body">
>>   <table width="100%" border="0" cellspacing="5">
>>     <tr>
>>       <td width="50%">
>>
>> ${screens.render("component://ar/widget/opentaps/collections/screens/Collect 
>>
>> ionScreens.xml#collectionWorkArea")}
>>       </td>
>>       <td width="50%">
>>             <#if chartURL?has_content>
>>             <img src="${chartURL}" style="vertical-align:middle;
>> margin-left:35px"/>
>>          <#else>
>>             No chart Image
>>          </#if>
>>        </td>
>>     </tr>
>> </table>
>> </div>
>> <#else>
>>   ${uiLabelMap.PartyNoPartyFoundWithPartyId}:
>> ${parameters.partyId?if_exists}
>> </#if>
>>
>>
>>
>> -----Original Message-----
>> From: Jonathon -- Improov [mailto:jonw@improov.com]
>> Sent: Tuesday, December 04, 2007 1:02 AM
>> To: user@ofbiz.apache.org
>> Subject: Re: Any plan to allow field widgets like <drop-down> inside
>> <screen>?
>>
>>
>> Skip,
>>
>> Do you mean it can currently be done already? Didn't know this.
>>
>> Or you mean it's a good step forward?
>>
>> Right now, whenever widgets are inadequate, a common practice (maybe the
>> only feasible one) is to
>> jump right into FTL and forget about widgets.
>>
>> (But if you can do all-widget forms and all-ftl forms, they do mix. I
>> replied to your post about
>> the "screens as building blocks" thing.)
>>
>> The lack of widgets (like convenient <drop-down>) in FTL is possibly the
>> main motivation behind Si
>> Chen's (opentaps) route with FreeMarker macros. Was mine too, at one 
>> time. I
>> had a library of
>> macros (sold, privatized, again, sigh).
>>
>> Jonathon
>>
>> skip@thedevers wrote:
>>> Widgets in FTL is the only way currently to get some things done if you
>> want
>>> to use widgets.
>>>
>>> Skip
>>>
>>> -----Original Message-----
>>> From: Jonathon -- Improov [mailto:jonw@improov.com]
>>> Sent: Monday, December 03, 2007 5:36 PM
>>> To: user@ofbiz.apache.org
>>> Subject: Re: Any plan to allow field widgets like <drop-down> inside
>>> <screen>?
>>>
>>>
>>> Actually, this isn't going backwards. It's going forward.
>>>
>>> Some screens are best done in ftl. This was discussed countless times
>>> before.
>>>
>>> In getting ftl screens to use field widgets, we reuse more of OFBiz's
>>> widgets in more places. This
>>> will bring us closer to using more of widgets.
>>>
>>> Jonathon
>>>
>>> BJ Freeman wrote:
>>>> seems your going backwards.
>>>> remove the ftl and use screen widgets that include formwidgets.
>>>> add a class (style) and use the css for aligning tables.
>>>>
>>>> Jonathon -- Improov sent the following on 12/2/2007 8:48 PM:
>>>>> The problem I'm facing now is that form widgets always have the start
>>>>> and end wrappers (<table cellspacing...> and </table). It is not
>>>>> possible to mix fields from one form into another form done in ftl.
>>>>>
>>>>> Attributes skip-start and skip-end only remove the <form> wrapper.
>>>>>
>>>>> Getting form widgets to say skip-table could solve this problem, 
>>>>> though
>>>>> it's not intuitive to use form widgets as field widgets. Better to use
>>>>> field widgets in screen widgets instead. However, this approach 
>>>>> could be
>>>>> a quick interim fix.
>>>>>
>>>>> Another problem is the colspan for <td>. Maybe we can make that
>> variable.
>>>>> Field widgets like <drop-down> are fantastic. It's a pity we can't use
>>>>> them inside of creative displays written in ftl.
>>>>>
>>>>> Si Chen did some FreeMarker macros for these, I believe. But if we're
>>>>> gonna strongly advocate widget usage, I think we need to fill that 
>>>>> void
>>>>> in screen widgets. Going the FreeMarker macros route would basically
>>>>> rewrite much of what is already provided by field widgets.
>>>>>
>>>>> Maybe have a generic "group of fields" widget via <fields>?
>>>>>
>>>>> Jonathon
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>>
>>
> 
> 

Re: Any plan to allow field widgets like inside ?

[Jonathon -- Improov <jo...@improov.com>]

Skip,

Yes, I knew we can include screen widgets in FTL. I told you "screens as building blocks", remember?

Also, check out ${sections.render('section_name')}, by the way.

My problem is that I can't add less than a screen in FTL.

Consider that you have in FTL a HTML form. Somewhere inside that form, you want to insert a 
<drop-down> widget. You can't, so you do what Si Chen did, using FreeMarker macros.

Why are we doing a HTML form in FTL? Because as discussed often before, some UIs just need to be 
complex and pretty and requires FTL.

Why am I trying to include <drop-down> widget into a HTML form in FTL? Because it's more complex 
to use FTL <select>. Let me give a concrete example. See 
${component:party}/webapp/partymgr/party/editcontactmech.ftl .

See lines:

   <select name="stateProvinceGeoId">
     <option>${(mechMap.postalAddress.stateProvinceGeoId)?if_exists}</option>
     <option></option>
     ${screens.render("component://common/widget/CommonScreens.xml#states")}
   </select>

Looks simple enough?

See screen widget ${component:common}/widget/CommonScreens.xml#states . It points to another FTL 
file in /framework/common/webcommon/includes/states.ftl . Look in that states.ftl , and see how a 
non-trivial CommonWorkers class is used.

If we can use widgets, it's just:

<field name="geoId">
   <drop-down>
     <entity-options entity-name="Geo" description="${geoName}" combine="or">
       <entity-constraint name="geoTypeId" value="STATE">
       <entity-constraint name="geoTypeId" value="PROVINCE">
       <entity-order-by field-name="geoName"/>
     </entity-options>
   </drop-down>
</field>

Compare the above <field> to the alternative now. See the <select> chunk, plus the <screen 
name="states"> chunk, plus the states.ftl, plus the CommonWorkers.getStateList() chunk.

Note note! The attribute "combine" in element <entity-options> does not exist... yet. :) 
Currently, all <entity-constraint> elements are "ANDed" together, not "ORed".

Jonathon

skip@thedevers wrote:
> Yep, you can already do it,  check out the screens.render line
> 
> #if collectionSummary?has_content>
> <div class="screenlet-body">
>   <table width="100%" border="0" cellspacing="5">
>     <tr>
>       <td width="50%">
> 
> ${screens.render("component://ar/widget/opentaps/collections/screens/Collect
> ionScreens.xml#collectionWorkArea")}
>       </td>
>       <td width="50%">
>    	     <#if chartURL?has_content>
>             <img src="${chartURL}" style="vertical-align:middle;
> margin-left:35px"/>
>          <#else>
>             No chart Image
>          </#if>
>        </td>
>     </tr>
> </table>
> </div>
> <#else>
>   ${uiLabelMap.PartyNoPartyFoundWithPartyId}:
> ${parameters.partyId?if_exists}
> </#if>
> 
> 
> 
> -----Original Message-----
> From: Jonathon -- Improov [mailto:jonw@improov.com]
> Sent: Tuesday, December 04, 2007 1:02 AM
> To: user@ofbiz.apache.org
> Subject: Re: Any plan to allow field widgets like <drop-down> inside
> <screen>?
> 
> 
> Skip,
> 
> Do you mean it can currently be done already? Didn't know this.
> 
> Or you mean it's a good step forward?
> 
> Right now, whenever widgets are inadequate, a common practice (maybe the
> only feasible one) is to
> jump right into FTL and forget about widgets.
> 
> (But if you can do all-widget forms and all-ftl forms, they do mix. I
> replied to your post about
> the "screens as building blocks" thing.)
> 
> The lack of widgets (like convenient <drop-down>) in FTL is possibly the
> main motivation behind Si
> Chen's (opentaps) route with FreeMarker macros. Was mine too, at one time. I
> had a library of
> macros (sold, privatized, again, sigh).
> 
> Jonathon
> 
> skip@thedevers wrote:
>> Widgets in FTL is the only way currently to get some things done if you
> want
>> to use widgets.
>>
>> Skip
>>
>> -----Original Message-----
>> From: Jonathon -- Improov [mailto:jonw@improov.com]
>> Sent: Monday, December 03, 2007 5:36 PM
>> To: user@ofbiz.apache.org
>> Subject: Re: Any plan to allow field widgets like <drop-down> inside
>> <screen>?
>>
>>
>> Actually, this isn't going backwards. It's going forward.
>>
>> Some screens are best done in ftl. This was discussed countless times
>> before.
>>
>> In getting ftl screens to use field widgets, we reuse more of OFBiz's
>> widgets in more places. This
>> will bring us closer to using more of widgets.
>>
>> Jonathon
>>
>> BJ Freeman wrote:
>>> seems your going backwards.
>>> remove the ftl and use screen widgets that include formwidgets.
>>> add a class (style) and use the css for aligning tables.
>>>
>>> Jonathon -- Improov sent the following on 12/2/2007 8:48 PM:
>>>> The problem I'm facing now is that form widgets always have the start
>>>> and end wrappers (<table cellspacing...> and </table). It is not
>>>> possible to mix fields from one form into another form done in ftl.
>>>>
>>>> Attributes skip-start and skip-end only remove the <form> wrapper.
>>>>
>>>> Getting form widgets to say skip-table could solve this problem, though
>>>> it's not intuitive to use form widgets as field widgets. Better to use
>>>> field widgets in screen widgets instead. However, this approach could be
>>>> a quick interim fix.
>>>>
>>>> Another problem is the colspan for <td>. Maybe we can make that
> variable.
>>>> Field widgets like <drop-down> are fantastic. It's a pity we can't use
>>>> them inside of creative displays written in ftl.
>>>>
>>>> Si Chen did some FreeMarker macros for these, I believe. But if we're
>>>> gonna strongly advocate widget usage, I think we need to fill that void
>>>> in screen widgets. Going the FreeMarker macros route would basically
>>>> rewrite much of what is already provided by field widgets.
>>>>
>>>> Maybe have a generic "group of fields" widget via <fields>?
>>>>
>>>> Jonathon
>>>>
>>>>
>>>>
>>
>>
> 
> 
> 

RE: Any plan to allow field widgets like inside ?

["skip@thedevers" <sk...@thedevers.org>]

Yep, you can already do it,  check out the screens.render line

#if collectionSummary?has_content>
<div class="screenlet-body">
  <table width="100%" border="0" cellspacing="5">
    <tr>
      <td width="50%">

${screens.render("component://ar/widget/opentaps/collections/screens/Collect
ionScreens.xml#collectionWorkArea")}
      </td>
      <td width="50%">
   	     <#if chartURL?has_content>
            <img src="${chartURL}" style="vertical-align:middle;
margin-left:35px"/>
         <#else>
            No chart Image
         </#if>
       </td>
    </tr>
</table>
</div>
<#else>
  ${uiLabelMap.PartyNoPartyFoundWithPartyId}:
${parameters.partyId?if_exists}
</#if>



-----Original Message-----
From: Jonathon -- Improov [mailto:jonw@improov.com]
Sent: Tuesday, December 04, 2007 1:02 AM
To: user@ofbiz.apache.org
Subject: Re: Any plan to allow field widgets like <drop-down> inside
<screen>?


Skip,

Do you mean it can currently be done already? Didn't know this.

Or you mean it's a good step forward?

Right now, whenever widgets are inadequate, a common practice (maybe the
only feasible one) is to
jump right into FTL and forget about widgets.

(But if you can do all-widget forms and all-ftl forms, they do mix. I
replied to your post about
the "screens as building blocks" thing.)

The lack of widgets (like convenient <drop-down>) in FTL is possibly the
main motivation behind Si
Chen's (opentaps) route with FreeMarker macros. Was mine too, at one time. I
had a library of
macros (sold, privatized, again, sigh).

Jonathon

skip@thedevers wrote:
> Widgets in FTL is the only way currently to get some things done if you
want
> to use widgets.
>
> Skip
>
> -----Original Message-----
> From: Jonathon -- Improov [mailto:jonw@improov.com]
> Sent: Monday, December 03, 2007 5:36 PM
> To: user@ofbiz.apache.org
> Subject: Re: Any plan to allow field widgets like <drop-down> inside
> <screen>?
>
>
> Actually, this isn't going backwards. It's going forward.
>
> Some screens are best done in ftl. This was discussed countless times
> before.
>
> In getting ftl screens to use field widgets, we reuse more of OFBiz's
> widgets in more places. This
> will bring us closer to using more of widgets.
>
> Jonathon
>
> BJ Freeman wrote:
>> seems your going backwards.
>> remove the ftl and use screen widgets that include formwidgets.
>> add a class (style) and use the css for aligning tables.
>>
>> Jonathon -- Improov sent the following on 12/2/2007 8:48 PM:
>>> The problem I'm facing now is that form widgets always have the start
>>> and end wrappers (<table cellspacing...> and </table). It is not
>>> possible to mix fields from one form into another form done in ftl.
>>>
>>> Attributes skip-start and skip-end only remove the <form> wrapper.
>>>
>>> Getting form widgets to say skip-table could solve this problem, though
>>> it's not intuitive to use form widgets as field widgets. Better to use
>>> field widgets in screen widgets instead. However, this approach could be
>>> a quick interim fix.
>>>
>>> Another problem is the colspan for <td>. Maybe we can make that
variable.
>>>
>>> Field widgets like <drop-down> are fantastic. It's a pity we can't use
>>> them inside of creative displays written in ftl.
>>>
>>> Si Chen did some FreeMarker macros for these, I believe. But if we're
>>> gonna strongly advocate widget usage, I think we need to fill that void
>>> in screen widgets. Going the FreeMarker macros route would basically
>>> rewrite much of what is already provided by field widgets.
>>>
>>> Maybe have a generic "group of fields" widget via <fields>?
>>>
>>> Jonathon
>>>
>>>
>>>
>>
>
>
>

Re: Any plan to allow field widgets like inside ?

[Jonathon -- Improov <jo...@improov.com>]

Skip,

Do you mean it can currently be done already? Didn't know this.

Or you mean it's a good step forward?

Right now, whenever widgets are inadequate, a common practice (maybe the only feasible one) is to 
jump right into FTL and forget about widgets.

(But if you can do all-widget forms and all-ftl forms, they do mix. I replied to your post about 
the "screens as building blocks" thing.)

The lack of widgets (like convenient <drop-down>) in FTL is possibly the main motivation behind Si 
Chen's (opentaps) route with FreeMarker macros. Was mine too, at one time. I had a library of 
macros (sold, privatized, again, sigh).

Jonathon

skip@thedevers wrote:
> Widgets in FTL is the only way currently to get some things done if you want
> to use widgets.
> 
> Skip
> 
> -----Original Message-----
> From: Jonathon -- Improov [mailto:jonw@improov.com]
> Sent: Monday, December 03, 2007 5:36 PM
> To: user@ofbiz.apache.org
> Subject: Re: Any plan to allow field widgets like <drop-down> inside
> <screen>?
> 
> 
> Actually, this isn't going backwards. It's going forward.
> 
> Some screens are best done in ftl. This was discussed countless times
> before.
> 
> In getting ftl screens to use field widgets, we reuse more of OFBiz's
> widgets in more places. This
> will bring us closer to using more of widgets.
> 
> Jonathon
> 
> BJ Freeman wrote:
>> seems your going backwards.
>> remove the ftl and use screen widgets that include formwidgets.
>> add a class (style) and use the css for aligning tables.
>>
>> Jonathon -- Improov sent the following on 12/2/2007 8:48 PM:
>>> The problem I'm facing now is that form widgets always have the start
>>> and end wrappers (<table cellspacing...> and </table). It is not
>>> possible to mix fields from one form into another form done in ftl.
>>>
>>> Attributes skip-start and skip-end only remove the <form> wrapper.
>>>
>>> Getting form widgets to say skip-table could solve this problem, though
>>> it's not intuitive to use form widgets as field widgets. Better to use
>>> field widgets in screen widgets instead. However, this approach could be
>>> a quick interim fix.
>>>
>>> Another problem is the colspan for <td>. Maybe we can make that variable.
>>>
>>> Field widgets like <drop-down> are fantastic. It's a pity we can't use
>>> them inside of creative displays written in ftl.
>>>
>>> Si Chen did some FreeMarker macros for these, I believe. But if we're
>>> gonna strongly advocate widget usage, I think we need to fill that void
>>> in screen widgets. Going the FreeMarker macros route would basically
>>> rewrite much of what is already provided by field widgets.
>>>
>>> Maybe have a generic "group of fields" widget via <fields>?
>>>
>>> Jonathon
>>>
>>>
>>>
>>
> 
> 
> 

RE: Any plan to allow field widgets like inside ?

["skip@thedevers" <sk...@thedevers.org>]

Widgets in FTL is the only way currently to get some things done if you want
to use widgets.

Skip

-----Original Message-----
From: Jonathon -- Improov [mailto:jonw@improov.com]
Sent: Monday, December 03, 2007 5:36 PM
To: user@ofbiz.apache.org
Subject: Re: Any plan to allow field widgets like <drop-down> inside
<screen>?


Actually, this isn't going backwards. It's going forward.

Some screens are best done in ftl. This was discussed countless times
before.

In getting ftl screens to use field widgets, we reuse more of OFBiz's
widgets in more places. This
will bring us closer to using more of widgets.

Jonathon

BJ Freeman wrote:
> seems your going backwards.
> remove the ftl and use screen widgets that include formwidgets.
> add a class (style) and use the css for aligning tables.
>
> Jonathon -- Improov sent the following on 12/2/2007 8:48 PM:
>> The problem I'm facing now is that form widgets always have the start
>> and end wrappers (<table cellspacing...> and </table). It is not
>> possible to mix fields from one form into another form done in ftl.
>>
>> Attributes skip-start and skip-end only remove the <form> wrapper.
>>
>> Getting form widgets to say skip-table could solve this problem, though
>> it's not intuitive to use form widgets as field widgets. Better to use
>> field widgets in screen widgets instead. However, this approach could be
>> a quick interim fix.
>>
>> Another problem is the colspan for <td>. Maybe we can make that variable.
>>
>> Field widgets like <drop-down> are fantastic. It's a pity we can't use
>> them inside of creative displays written in ftl.
>>
>> Si Chen did some FreeMarker macros for these, I believe. But if we're
>> gonna strongly advocate widget usage, I think we need to fill that void
>> in screen widgets. Going the FreeMarker macros route would basically
>> rewrite much of what is already provided by field widgets.
>>
>> Maybe have a generic "group of fields" widget via <fields>?
>>
>> Jonathon
>>
>>
>>
>
>

Re: Any plan to allow field widgets like inside ?

[Jonathon -- Improov <jo...@improov.com>]

Actually, this isn't going backwards. It's going forward.

Some screens are best done in ftl. This was discussed countless times before.

In getting ftl screens to use field widgets, we reuse more of OFBiz's widgets in more places. This 
will bring us closer to using more of widgets.

Jonathon

BJ Freeman wrote:
> seems your going backwards.
> remove the ftl and use screen widgets that include formwidgets.
> add a class (style) and use the css for aligning tables.
> 
> Jonathon -- Improov sent the following on 12/2/2007 8:48 PM:
>> The problem I'm facing now is that form widgets always have the start
>> and end wrappers (<table cellspacing...> and </table). It is not
>> possible to mix fields from one form into another form done in ftl.
>>
>> Attributes skip-start and skip-end only remove the <form> wrapper.
>>
>> Getting form widgets to say skip-table could solve this problem, though
>> it's not intuitive to use form widgets as field widgets. Better to use
>> field widgets in screen widgets instead. However, this approach could be
>> a quick interim fix.
>>
>> Another problem is the colspan for <td>. Maybe we can make that variable.
>>
>> Field widgets like <drop-down> are fantastic. It's a pity we can't use
>> them inside of creative displays written in ftl.
>>
>> Si Chen did some FreeMarker macros for these, I believe. But if we're
>> gonna strongly advocate widget usage, I think we need to fill that void
>> in screen widgets. Going the FreeMarker macros route would basically
>> rewrite much of what is already provided by field widgets.
>>
>> Maybe have a generic "group of fields" widget via <fields>?
>>
>> Jonathon
>>
>>
>>
> 
> 

Re: Any plan to allow field widgets like inside ?

[BJ Freeman <bj...@free-man.net>]

seems your going backwards.
remove the ftl and use screen widgets that include formwidgets.
add a class (style) and use the css for aligning tables.

Jonathon -- Improov sent the following on 12/2/2007 8:48 PM:
> The problem I'm facing now is that form widgets always have the start
> and end wrappers (<table cellspacing...> and </table). It is not
> possible to mix fields from one form into another form done in ftl.
> 
> Attributes skip-start and skip-end only remove the <form> wrapper.
> 
> Getting form widgets to say skip-table could solve this problem, though
> it's not intuitive to use form widgets as field widgets. Better to use
> field widgets in screen widgets instead. However, this approach could be
> a quick interim fix.
> 
> Another problem is the colspan for <td>. Maybe we can make that variable.
> 
> Field widgets like <drop-down> are fantastic. It's a pity we can't use
> them inside of creative displays written in ftl.
> 
> Si Chen did some FreeMarker macros for these, I believe. But if we're
> gonna strongly advocate widget usage, I think we need to fill that void
> in screen widgets. Going the FreeMarker macros route would basically
> rewrite much of what is already provided by field widgets.
> 
> Maybe have a generic "group of fields" widget via <fields>?
> 
> Jonathon
> 
> 
>