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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>>>>
>>>
> 
>