Any plan to allow field widgets like <drop-down> inside <screen>?

[Jacques Le Roux]

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

Jacques

De : "Jonathon -- Improov" <[hidden email]>

> 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:[hidden email]]
> >>> Sent: Tuesday, December 04, 2007 1:02 AM
> >>> To: [hidden email]
> >>> 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:[hidden email]]
> >>>> Sent: Monday, December 03, 2007 5:36 PM
> >>>> To: [hidden email]
> >>>> 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
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
>

[jonwimp]

 > 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:[hidden email]]
>>>>> Sent: Tuesday, December 04, 2007 1:02 AM
>>>>> To: [hidden email]
>>>>> 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:[hidden email]]
>>>>>> Sent: Monday, December 03, 2007 5:36 PM
>>>>>> To: [hidden email]
>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>
>