You referred to such a case in point in an earlier mail - i.e the
displayApps/displaySecondaryApps in the main-navigation. Other examples
that come to mind are a list of available languages, list of visual themes,
a task list - all of which could be presented as dropdown options -
eliminating the need for a additional request and screen.

Gavin

On Thu, Oct 30, 2014 at 6:45 PM, Adrian Crum <
[email protected]> wrote:

> That is not possible with the current architecture. The widget models are
> supposed to be read-only.
>
> What is the use case?
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 10/30/2014 3:17 PM, Gavin Mabie wrote:
>
>> Wish
>>
>> It would be super cool if we had an iterator inside the menu widget.  That
>> would allow for dynamic menu item generation. Or does it exist?
>>
>> Gavin
>>
>> On Thu, Oct 30, 2014 at 1:12 PM, Scott Gray <[email protected]>
>> wrote:
>>
>>  Yeah he did a great job implementing the macro renderer.  We discussed
>>> the
>>> idea many years ago and he turned it into something real (which is
>>> definitely the hard part).
>>>
>>> I'd be interested to hear what integration steps you might take for
>>> angularjs, I've been through the tutorials lately and it looks promising
>>> as
>>> a front-end framework.  But it seems to use static html templates
>>> delivered
>>> to the client so I'm unsure how OFBiz would play a role other than
>>> providing the web services.
>>>
>>> Regards
>>> Scott
>>>
>>> On 30/10/2014, at 11:21 pm, Adrian Crum <
>>> [email protected]> wrote:
>>>
>>>  Actually, the idea was Jacopo's - when he first introduced the macro
>>>>
>>> screen renderer years ago.
>>>
>>>>
>>>> I exploited that feature to use the Sencha JS framework in OFBiz for one
>>>>
>>> of our clients. Our current client uses Angular JS, so I expect to be
>>> integrating Angular for them. And right now the OFBiz community is
>>> working
>>> on integrating Bootstrap.
>>>
>>>>
>>>> So, the capability has been there all along, but no one used it until
>>>>
>>> now.
>>>
>>>>
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>> On 10/30/2014 9:51 AM, Scott Gray wrote:
>>>>
>>>>> That's a great idea! Thanks for implementing it
>>>>>
>>>>> On 30 October 2014 20:31:06 GMT+13:00, Adrian Crum <
>>>>>
>>>> [email protected]> wrote:
>>>
>>>> I modified the MacroScreenViewHandler in rev 1635411. Themes can create
>>>>>>
>>>>>> their own HTML now.
>>>>>>
>>>>>> Adrian Crum
>>>>>> Sandglass Software
>>>>>> www.sandglass-software.com
>>>>>>
>>>>>> On 10/30/2014 6:37 AM, Gavin Mabie wrote:
>>>>>>
>>>>>>> Julien,
>>>>>>>
>>>>>>> I think that we are actually in agreement about minimizing (even
>>>>>>>
>>>>>> avoiding)
>>>>>>
>>>>>>> framework modifications. Maybe we need to further explore exactly
>>>>>>>
>>>>>> what
>>>>>>
>>>>>>> qualifies as part of the framework. As Adrian stated in an earlier
>>>>>>>
>>>>>> mail on
>>>>>>
>>>>>>> the subject: "The Widget Models and Renderer are output agnostic -
>>>>>>>
>>>>>> they
>>>>>>
>>>>>>> don't "know" what type of output is being generated. So those
>>>>>>>
>>>>>> artifacts do
>>>>>>
>>>>>>> not need to be changed to support Bootstrap.
>>>>>>>
>>>>>>> The only things that need to be changed to support Bootstrap (sic or
>>>>>>>
>>>>>> any
>>>>>>
>>>>>>> other frontend framework) are the FreeMarker macros - so that they
>>>>>>>
>>>>>> output
>>>>>>
>>>>>>> Bootstrap HTML + CSS instead of the current OFBiz-specific HTML +
>>>>>>>
>>>>>> CSS."
>>>>>>
>>>>>>>
>>>>>>> Following this line of thinking, creating specific Bootstrap macros
>>>>>>>
>>>>>> should
>>>>>>
>>>>>>> not be considered as changing the framework.  Maybe we need a
>>>>>>>
>>>>>> practical
>>>>>>
>>>>>>> example to illustrate this.
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> Gavin
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Oct 29, 2014 at 11:19 PM, Julien NICOLAS
>>>>>>>
>>>>>> <[email protected]>
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>  Hi,
>>>>>>>>
>>>>>>>> I'm sorry but I'm not sure to understand well the goal...
>>>>>>>> We'll modify the framework to match with bootstrap but, if we have
>>>>>>>>
>>>>>>> to do
>>>>>>
>>>>>>> UI modification, we have to do it in the framework ?!
>>>>>>>> If macros stay in the framework I don't understand how to be as
>>>>>>>>
>>>>>>> flexible
>>>>>>
>>>>>>> as we need if anytime we have to change framework...
>>>>>>>>
>>>>>>>> My question is : with your example, you'll define compatible
>>>>>>>>
>>>>>>> bootstrap
>>>>>>
>>>>>>> navbars. But if I want to add something new in it (like avatar
>>>>>>>>
>>>>>>> picture or
>>>>>>
>>>>>>> other feature), do I must change the framework ?
>>>>>>>> If the answer is yes, I think we are on the wrong way...
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Julien.
>>>>>>>>
>>>>>>>> Le 29/10/2014 17:09, Gavin Mabie a écrit :
>>>>>>>>
>>>>>>>>    Hi Julien, Adrian
>>>>>>>>
>>>>>>>>>
>>>>>>>>> IMO that we should try to define all menus via menu widgets. So I'm
>>>>>>>>> inclined to agree with Adrian on the issue of the main-navigation
>>>>>>>>>
>>>>>>>> menu.
>>>>>>
>>>>>>> Maybe this is something we should include in our Bootstrap project.
>>>>>>>>> Loading macros as Visual Visual Theme resources might also address
>>>>>>>>> Julien's
>>>>>>>>> wish to have a more generic way to integrate front-end frameworks.
>>>>>>>>>
>>>>>>>> I also
>>>>>>
>>>>>>> support the suggestion that we copy the existing macro to the to be
>>>>>>>>> created
>>>>>>>>> Bootstrap theme and to modify them, as per Adrian's suggestion.  We
>>>>>>>>>
>>>>>>>> can
>>>>>>
>>>>>>> then address the sub-menu issue in the macros.
>>>>>>>>>
>>>>>>>>> Gavin
>>>>>>>>>
>>>>>>>>> On Wed, Oct 29, 2014 at 4:50 PM, Adrian Crum <
>>>>>>>>> [email protected]> wrote:
>>>>>>>>>
>>>>>>>>>    If you are referring to the main navigation menu:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> <div id="main-navigation">
>>>>>>>>>>
>>>>>>>>>> that uses a template instead of a menu widget - it is done that
>>>>>>>>>>
>>>>>>>>> way
>>>>>>
>>>>>>> simply
>>>>>>>>>> because no one has tried to do it differently. Personally, I would
>>>>>>>>>>
>>>>>>>>> like
>>>>>>
>>>>>>> to
>>>>>>>>>> see it changed to a menu widget.
>>>>>>>>>>
>>>>>>>>>> Regarding the existing FreeMarker macros: those should be copied
>>>>>>>>>>
>>>>>>>>> to the
>>>>>>
>>>>>>> Bootstrap theme and modified to output Bootstrap-specific HTML. To
>>>>>>>>>>
>>>>>>>>> use
>>>>>>
>>>>>>> the
>>>>>>>>>> Bootstrap theme, you will need to modify widget.properties to
>>>>>>>>>>
>>>>>>>>> reference
>>>>>>
>>>>>>> the
>>>>>>>>>> Bootstrap macros.
>>>>>>>>>>
>>>>>>>>>> It would be nice to have a more dynamic way to change macros, but
>>>>>>>>>>
>>>>>>>>> it
>>>>>>
>>>>>>> might
>>>>>>>>>> be best to put that idea on the shelf for now. (Maybe we can make
>>>>>>>>>>
>>>>>>>>> the
>>>>>>
>>>>>>> macro
>>>>>>>>>> file locations Visual Theme resources - store them in the
>>>>>>>>>>
>>>>>>>>> database.)
>>>>>>
>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Adrian Crum
>>>>>>>>>> Sandglass Software
>>>>>>>>>> www.sandglass-software.com
>>>>>>>>>>
>>>>>>>>>> On 10/29/2014 2:28 PM, Julien NICOLAS wrote:
>>>>>>>>>>
>>>>>>>>>>    Adrian,
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It's just : Why html structure for sub-menu is not managed like
>>>>>>>>>>>
>>>>>>>>>> main
>>>>>>
>>>>>>> menu
>>>>>>>>>>> ?
>>>>>>>>>>>
>>>>>>>>>>> Is it possible to use sub-menu like main menu ?
>>>>>>>>>>> Maybe we can move macro from framework folder to theme folder.
>>>>>>>>>>>
>>>>>>>>>>> hope you understand better in this way :)
>>>>>>>>>>>
>>>>>>>>>>> Thanks for your help,
>>>>>>>>>>>
>>>>>>>>>>> Julien.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Le 29/10/2014 15:22, Adrian Crum a écrit :
>>>>>>>>>>>
>>>>>>>>>>>    I don't understand the question. Could you ask it in another
>>>>>>>>>>>
>>>>>>>>>> way
>>>>>>
>>>>>>> please?
>>>>>>>>>>>>
>>>>>>>>>>>> Adrian Crum
>>>>>>>>>>>> Sandglass Software
>>>>>>>>>>>> www.sandglass-software.com
>>>>>>>>>>>>
>>>>>>>>>>>> On 10/29/2014 1:39 PM, Julien NICOLAS wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>    Hi Gavin, Adrian and all,
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I was thinking about move sub-menu generation by header.ftl or
>>>>>>>>>>>>> appbarOpen.ftl in theme folder like main menu...
>>>>>>>>>>>>> Can we move the macro in the theme folder or create a service
>>>>>>>>>>>>>
>>>>>>>>>>>> that
>>>>>>
>>>>>>> send
>>>>>>>>>>>>> sub-menu entry sorted list ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> It could be useful to create specific webdesign if this section
>>>>>>>>>>>>>
>>>>>>>>>>>> could
>>>>>>
>>>>>>> be
>>>>>>>>>>>>> managed manually.
>>>>>>>>>>>>>
>>>>>>>>>>>>> What's your opinion ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Julien.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Le 29/10/2014 12:07, Gavin Mabie a écrit :
>>>>>>>>>>>>>
>>>>>>>>>>>>>    Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As I'm working on the bootstrap theme branch, I notice that:
>>>>>>>>>>>>>> 1. menuStringRenderer is out-commettted in the
>>>>>>>>>>>>>>
>>>>>>>>>>>>> MacroScreenViewhandler
>>>>>>
>>>>>>> class;
>>>>>>>>>>>>>> 2. This being the case, that menus get rendered by default
>>>>>>>>>>>>>>
>>>>>>>>>>>>> through
>>>>>>
>>>>>>> the
>>>>>>>>>>>>>> HtmlMenuRenderer class;
>>>>>>>>>>>>>> 3. The latter automatically creates <ul><li><ul> opening tags
>>>>>>>>>>>>>>
>>>>>>>>>>>>> for
>>>>>>
>>>>>>> every
>>>>>>>>>>>>>> menus included in a screen definition with a menu item count
>>>>>>>>>>>>>>
>>>>>>>>>>>>> bigger
>>>>>>
>>>>>>> than 0;
>>>>>>>>>>>>>> 4.  This results in an extra <ul> - the first one;
>>>>>>>>>>>>>> 5.  menu item count does not take sub-menus into account - in
>>>>>>>>>>>>>>
>>>>>>>>>>>>> fact,
>>>>>>
>>>>>>> although defined in the xsd, I could not find any examples of
>>>>>>>>>>>>>>
>>>>>>>>>>>>> the
>>>>>>
>>>>>>> sub-menu
>>>>>>>>>>>>>> attribute in any of the *menu,xml.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is this an issue?Common sense tells me that the
>>>>>>>>>>>>>>
>>>>>>>>>>>>> menuStringRendere was
>>>>>>
>>>>>>> (is)
>>>>>>>>>>>>>> part pf the architecture, but that a conscious decision was
>>>>>>>>>>>>>>
>>>>>>>>>>>>> made to
>>>>>>
>>>>>>> rather
>>>>>>>>>>>>>> leave it out.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Some guidance please?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Gavin
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>>
>>

Reply via email to