web2py "Components" for layout.html and other HTML pages [ not derived from layout.html]

[JoeCodeswell]

Dear web2py Forum,

Often i find myself making View pages that are NOT derived from layout.html and yet wanting to include some aspects of its capabilities.

I thought the web2py "Component" concept might help to deliver a modular approach.

My initial thoughts would be to pair small CSS files and HTML Component definitions for the following:

• menu
• login/register
• left sidebar
• right sidebar
• footer
• ajax
• flash response
• mobile
• responsive
  

while maintaining a list of dependencies among them.

Has anyone thought about this granular approach before?

I would not want to use a Wizard for this, because in my experience, the generated code is unfamiliar to me and difficult to customize.

Thanks for a GREAT framework.

Love and peace,

Joe

[Anthony]

You can also build a layout by using {{include 'some_fragment.html'}} as well as template blocks. You could have a basic layout that defines several (possibly empty) blocks, and then have various additional layouts that extend the basic layout and fill in the blocks as needed. 

Anthony

[Kiran Subbaraman]

+ 1. This is something I would like to have - makes it easier to create custom layouts.
The separate "layout components" are defined the way you mention, with the out-of-the-box layout.html being a good example that combines all of them to good effect.

________________________________________
Kiran Subbaraman
http://subbaraman.wordpress.com/about/

--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google Groups "web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Johann Spies]

+1

--
Because experiencing your loyal love is better than life itself,
my lips will praise you.  (Psalm 63:3)

[JoeCodeswell]

Dear Anthony, Kiran and Johann,

Thanks for the responses.

I'll be keeping track of the work that i do on this subject on myblog at this post. If you or any other web2py-users group members have any comments or suggestions you can share them there or here.

As of now i have added 2 comments on the blog to my original post.

1. i looked up web2py component

By def it seems that components

communicate with the component controller function via Ajax

Therefore the list of dependencies must contain ajax stuff.

2. add a new component to list:

navbar – is a complex component containing both menu and auth-login components.

Thanks again for a GREAT framework.

Love and peace,

Joe

[Kiran Subbaraman]

Joe,
It is probably a good idea to capture this in the web2py bug tracker as an enhancement request.

________________________________________
Kiran Subbaraman
http://subbaraman.wordpress.com/about/

On 11/11/2013 10:22 PM, JoeCodeswell wrote:

Dear Anthony, Kiran and Johann,

Thanks for the responses.

I'll be keeping track of the work that i do on this subject on myblog at this post. If you or any other web2py-users group members have any comments or suggestions you can share them there or here.

As of now i have added 2 comments on the blog to my original post.

1. i looked up web2py component

By def it seems that components

communicate with the component controller function via Ajax

Therefore the list of dependencies must contain ajax stuff.

2. add a new component to list:

navbar � is a complex component containing both menu and auth-login components.

Thanks again for a GREAT framework.

Love and peace,

Joe



On Saturday, November 9, 2013 10:52:49 AM UTC-8, JoeCodeswell wrote:

Dear web2py Forum,

Often i find myself making View pages that are NOT derived from layout.html and yet wanting to include some aspects of its capabilities.

I thought the web2py "Component" concept might help to deliver a modular approach.

My initial thoughts would be to pair small CSS files and HTML Component definitions for the following:

• menu
• login/register
• left sidebar
• right sidebar
• footer
• ajax
• flash response
• mobile
• responsive
  

while maintaining a list of dependencies among them.

Has anyone thought about this granular approach before?

I would not want to use a Wizard for this, because in my experience, the generated code is unfamiliar to me and difficult to customize.

Thanks for a GREAT framework.

Love and peace,

Joe

[Anthony]

On Monday, November 11, 2013 9:27:23 PM UTC-5, Kiran Subbaraman wrote:

Joe,
It is probably a good idea to capture this in the web2py bug tracker as an enhancement request.

What exactly is being requested?

[Kiran Subbaraman]

My view is:
Splitting / refactoring the contents of the layout.html into 'components' - which contains a combination of css + html as mentioned in the original note: https://groups.google.com/forum/#!topic/web2py/3NmrocjbwzM

________________________________________
Kiran Subbaraman
http://subbaraman.wordpress.com/about/

[Anthony]

On Monday, November 11, 2013 11:28:37 PM UTC-5, Kiran Subbaraman wrote:

My view is:
Splitting / refactoring the contents of the layout.html into 'components' - which contains a combination of css + html as mentioned in the original note: https://groups.google.com/forum/#!topic/web2py/3NmrocjbwzM

Are you saying you'd like something like this to be offered as an optional alternative or to replace the current layout.html? I don't think we want to have separate Ajax requests for every little piece of the layout.

Note, the current layout is already fairly modular, with separate blocks for the head, center, sidebars, and footer. It also allows you to conditionally include the left and right sidebars, Auth navbar, menu, logo, flash message, page title, and subtitle (by setting various attributes and global variables in the model, controller, and extending view code).

Maybe it would help if you provide some examples of what you are trying to achieve so we can figure out the best approach. If you want to re-use pieces of the layout in alternative layouts, perhaps we could put each piece in a separate template file and then just use {{include ...}} statements to insert them where needed. This would probably be much more efficient than running multiple Ajax requests to get what could just as easily be generated in a single request.

Anthony

[Kiran Subbaraman]

I wasn't thinking in terms of Ajax calls to stitch together these components/templates, but rather the {{include...}} mechanism to do this.
I do agree that the current layout is modular, but then if I want re-use a piece of functionality present in that layout.html in some other page or in my own custom template, then I have to resort to cut-and-paste of the code. The intention is to keep this cut-and-paste to a minimum, or none at all.
The other thing to consider is what should be the granularity of these templates, and if the "configuration" that brings these templates together can be defined in a single place.

A sample of what am thinking (needs to be refined further): https://github.com/kirsn/web2py_layout_template/blob/master/views/layout.html

________________________________________
Kiran Subbaraman
http://subbaraman.wordpress.com/about/

[Vinicius Assef]

You can use LOAD(..., ajax=False).

Doesn't it help you?

[Anthony]

OK, the original suggestion was to use Ajax components, but using {{include}}'s certainly makes sense. I'm not sure how much of this we want to do in the scaffolding app, though. It makes the code a bit more complex to follow, and for non-compiled views, it will slow down the template processing as well. The scaffolding app is intended to be a basic starting point. If you have a special use case that requires multiple layouts that are different enough that they can't be generated from a single layout.html but that nevertheless need common components that themselves don't change from layout to layout, it's easy enough to break up the standard layout yourself in a way that exactly meets your needs (the example you linked would only take a few minutes to create).

Separating out at least some of the <head> section as well as the scripts section at the bottom of the layout might be particularly useful because those sections are not tied to the styling of the scaffolding app and should therefore be more portable to other layouts (in fact, part of the head section is already modularized into web2py_ajax.html).

Anthony

[Anthony]

On Tuesday, November 12, 2013 6:36:32 AM UTC-5, viniciusban wrote:

You can use LOAD(..., ajax=False).

That will still probably result in a lot of unnecessary processing relative to using simple {{include}} statements.

Anthony 

[JoeCodeswell]

Dear Anthony and other discussants,

My original thought was JUST to modularize GUI entities at a more granular level. I thought of Components [as in Microsoft land] and how web2py has the Component concept. So i thought "why not use it?"

Then i discovered that according to the book, web2py Component engineers were "interested" in Ajax being part of the infrastructure. So I began my research in that direction.

As far as I am concerned, as long as Components provide modularity, they can use Ajax or NOT as a matter of performance choice.

The modularity i am talking about links css, javascript and server-side dependencies for each Component so that it may be "included" statically or dynamically or via Ajax or NOT in the rendering of a page.

I am happy to have begun this discussion. I trust in the web2py community spirit to make progress in this direction.

Thanks for the GREAT framework.

Thanks EVEN MORE for the web2py community spirit.

Love and peace,

Joe

[Niphlod]

-1 for yet another complication on the scaffolding app.

@Joe: web2py has several ways to accomplish what you want, but all of them come with a cost (as anything else called "feature" in every framework of every programming language). There isn't a silver bullet that goes well with all kinds of "business requirements". Yep, ajax is fun but having a page with 64 'loading...' fragments is not going to be a nice page both from the user perspective and for your server, that needs to "reply" 64 times instead of just one to build the page.
Same thing goes for web2py having to dinamically figure out 64 "fragments" and compile them every time a user hits the page.
On the other end, you may find that your site needs a "modularized" approach only on some pages, and nothing in web2py prevents you to have different layout.html written as you wish, called as you like.
On the argument of having scripts, css and such inserted dynamically in fragments only when they're needed...unless you have 1MB of gzipped css and js.....it's really not a valid argument.
Just include all of them on the "index" page, and if cached correctly only the first page will be slowed down (maybe for 200ms ?!) . All subsequent fragments will not have to deal with them, as they are fetched from the browser's cache.

[JoeCodeswell]

Dear Niphlod,

Thanks for the detailed response.

You said:

Yep, ajax is fun but having a page with 64 ...

Right, Niphlod. I am agnostic on implementing modular Component with Ajax. Please see my previous post here in which i say:

As far as I am concerned, as long as Components provide modularity, they can use Ajax or NOT as a matter of performance choice.

I just want to modularize GUI entities and the code that supports them at a more granular level.

Thanks again, Niphlod.

Love and peace,

Joe

[JoeCodeswell]

It seems to me that "Form Widgets" as published in a Plugin form by s-cubism, and endorsed by The web2py Book - Plugins repositories could begin to present a skeleton around which this GUI Component work could begin coalesce.

I have also been investigating "code playgrounds" such as jsbin.com and jsfiddle.net which could help build and test HTML/CSS/JavaScript based "Widgets" to be published in a Plugin form.

Love and peace,

Joe

[Arnon Marcus]

+1
I was thinking the same thing, as a starting point in preperation of converting my we2py-app's client-side into a SPA. Having a componentized scaffold could help me get to that milestone faster.

I am not saying web2py should become a SPA framework, just a "frendlier" option for these use-case's starting point.

If there are 64 loadings it would become quite slow to start, but that would be true for any framework... It doesnt mean that it wouldn't be helpfull to do, say, 5 to 10 loadings...
The initial loading time would be easially compensated by the rest of the use of the app loading only the components that change to other ones (even in a non-SPA would benefit, by loading cached-versions). Otherwise the whole SPA movement would not have emearged.