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
>
> [EMAIL PROTECTED] 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:[EMAIL PROTECTED]
>> 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
>>
>> [EMAIL PROTECTED] 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:[EMAIL PROTECTED]
>>> 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
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>>
>>
>
>
>
>
