Re: Bootstrap Initiative

Fri, 31 Oct 2014 09:09:35 -0700

I don't understand what you mean, sorry. Could you state it another way please? 

I think you mean this:
If we create Bootstrap-specific markup using replacement macro libraries, then screens that use FreeMarker templates (instead of screen widgets) will break the Bootstrap layout with their OFBiz-specific markup.
Yes, that will be a problem, and a potential motivator for eliminating those templates. A possible workaround would be to style the OFBiz-specific markup to look like Bootstrap.
Sometimes those templates appear because there was a problem that couldn't be solved with screen widgets alone. In that case, we should see how we can extend the screen widget functionality to meet that need. 

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 10/31/2014 1:39 PM, Gavin Mabie wrote:

Adrian

Also with regards to using macroLibraries, I find that the
htmlScreenMacroLibrary.ftl only works with well-defined screen
definitions.  I elements such as screenlet-headers/bodies are created in
ftl files, then using the htmlScreenMacroLibrary.ftl is insufficient as it
get overridden by the .ftl file.I remember that there was a discussion some
time ago about limiting .ftl  in screen definitions and I can now see the
value of this.

Gavin

On Fri, Oct 31, 2014 at 3:11 PM, Gavin Mabie <[email protected]> wrote:


BTW I find that loading macroLibraries as visual theme resources
significantly slows down pageloading! Maybe caching can deal with this
problem.


Gavin

On Fri, Oct 31, 2014 at 3:06 PM, Gavin Mabie <[email protected]> wrote:


Hi Adrian, Julien All

I think we got disconnected somehow. The Visual Themes list can be

displayed with a form widget (used as a list) - so we don't need a menu
widget for that.


No doubt, its doable.  I'm sure you would agree that using form widget
lists as menus (in the strict sense of the word) would be at best a
work-a-round(if not a hack) and at worst inelegant. Maybe it's a
nice-to-have dynamically created menus at this stage - so it should not be
something that requires a scrum for us to move forward.  Let's see what
Julien comes up with!

I would also like to change how applications insert themselves in the

main navigation menu. Maybe something like (in ofbiz-component.xml):

<webapp name="accounting"
         title="Accounting"
         server="default-server"
         location="webapp/accounting"
         base-permission="OFBTOOLS,ACCO
UNTING"
         mount-point="/accounting">
     <navigation>
         <main>
             <title-property resource="AccountingUiLabels"
property="AccountingAccounting"/>
         </main>
         <!-- or secondary nav menu...
         <secondary>
             <title-property resource="AccountingUiLabels"
property="AccountingAccounting"/>
         </secondary>
         -->
         <!-- app-menu element enables main nav drop-downs -->
         <app-menu  name="AccountingAppBar"
location="component://accounting/widget/AccountingMenus.xml"/>
     </navigation>
</webapp>




  Despite the impact that this will have on hot-deployability, this looks
like a good idea for the production environment. In just, what would be the
advantage of loading the app-menu when the application is registered with
the server as opposed to when it is loaded as a request?

Gavin



On Fri, Oct 31, 2014 at 12:25 PM, Adrian Crum <
[email protected]> wrote:


I think we got disconnected somehow. The Visual Themes list can be
displayed with a form widget (used as a list) - so we don't need a menu
widget for that.

Regarding the main navigation - Due to its unique nature, I think we
should create a widget for it:

<main-navigation/>

The widget model would contain the logic currently found in the
individual visual theme header templates. This would eliminate a lot of
duplicate FreeMarker code.

I would also like to change how applications insert themselves in the
main navigation menu. Maybe something like (in ofbiz-component.xml):

<webapp name="accounting"
         title="Accounting"
         server="default-server"
         location="webapp/accounting"
         base-permission="OFBTOOLS,ACCOUNTING"
         mount-point="/accounting">
     <navigation>
         <main>
             <title-property resource="AccountingUiLabels" property="
AccountingAccounting"/>
         </main>
         <!-- or secondary nav menu...
         <secondary>
             <title-property resource="AccountingUiLabels" property="
AccountingAccounting"/>
         </secondary>
         -->
         <!-- app-menu element enables main nav drop-downs -->
         <app-menu  name="AccountingAppBar" location="component://
accounting/widget/AccountingMenus.xml"/>
     </navigation>
</webapp>

The <main-navigation> widget would use this information to render itself.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 10/31/2014 7:39 AM, Gavin Mabie wrote:


I'd be interested to see just how you would go about it, given the fact
that unlike screens, trees and forms, the widget-menu.xsd does not allow
for actions such as entity-condition etc.

Gavin

On Fri, Oct 31, 2014 at 8:33 AM, Adrian Crum <
[email protected]> wrote:

  Some of those lists can be rendered with the form widget.


We can create a widget for the main navigation.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 10/30/2014 11:15 PM, Gavin Mabie wrote:

  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