This discussion sounds interesting and should be rather done on the dev list,
suggesting...
Jacques
De : "Jonathon -- Improov" <[EMAIL PROTECTED]>
> 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
> >>
> >> [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
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
>
