There are two kind of web frameworks:
- push: the controller pushes variables to the view and out
- pull: the view calls the functions it needs to render parts of the
page
web2py is push. You are asking to implement pull as well.
I would not be opposed to a helper {{=LOAD(...)}}} that does something
like
{{=response.render(....,**exec_environement(...))}}
But I am not convinced this is the solution to the plugin design that
we want.
- it would be slow because it would do an exec inside an exec
- not clear how errors would be handed
- mixing pull and push gives you potentially circular references.
Although this can be avoided in practice the problem is that A calls B
which calls C and what should be the environment that C sees? How does
it know that A is the root?
- even if we implement something like {{load '....'}} we would still
have the issue of where to put the plugin file and how to name it.
- Why is it better than use {{include ...}} which we have already and
nobody seems to use.
Do we really want to build a pull plugin system on a push framework?
My proposed solution avoids the problem: the client is pull (and it is
already), the server is push (as it is now). You increase the number
of HTTP requests but you minimize the size of the data being
transmitted. In the end pages will look more responsive this way, not
slower. You may have 100 plugins but your are probably not embedding
more than 2-3 components/page. It is not that different than including
2/3 images.
My proposed solutions also allows to run components on a different
host than the one proving the main app which makes it easier to
distribute complex apps over multiple servers and make it work
seamlessly.
I do not envision all plugins to expose components via ajax, some will
just expose controllers in a normal way and extend the layout.
If we build admin to support my naming convention I can build plugins
my way and you can build plugins your way. You can create a load
helper based on exec_environment. Either case we do not need to change
web2py source code.
Let me break my original RFC in 3 parts:
1) what about making the new web2py_ajax in trunk the official one? Is
there anything wrong with it?
2) what about the naming convention for files (model/view/controllers)
that are functionally related? This is what most people do not like so
far. I do not like it either but, pragmatically, I think if do not get
this way we open a can of worm that will take very long to close.
3) What kind of plugin types do we want to provide? layout plugin?
ajax compoents? non-ajax components? can we do this in a minimally
disruptive way without changing the web2py source code by setting
conventions?
Massimo
On Oct 1, 4:24 pm, Álvaro Justen [Turicas] <alvarojus...@gmail.com>
wrote:
> On Wed, Sep 30, 2009 at 16:09, Massimo Di Pierro
>
> <mdipie...@cs.depaul.edu> wrote:
> > Here is a video explaining the proposal
>
> > http://vimeo.com/6836681
>
> > Attached is a document containing the proposal, the code, and
> > requesting help modify admin to do this.
>
> > This would make it easy to build a repository of plugins similar but
> > better than Drupal, reusable, more sexy via ajax, without having to
> > learn an new syntax.
>
> > Massimo
>
> Sincerely I don't like this.
> The idea of a plugin system is very good, but I didn't like this
> implementation.
> If I have 1 application with 10 plugins so visitor's browser will do
> 11 HTTP requests (1 for app and 10 async (AJAX)) and it must have
> javascript enabled! So all plugins that we create will need that
> visitor's browser have javascript enabled (some clientes don't have by
> default or by security issues (companies disabled it, for example),
> others DON'T have support for javascript etc.) and it will overload
> our webserver (11 requests instead of 1).
> I think that a plugin should interact with web2py app, not with
> browser - so what I propose is to change gluon/some-files.py to
> implement this, not necessarily changing only web2py_ajax.html.
> One thing that I'm thinking is to have a new reserved word in template
> system, for example, in myapp/views/default/test.html:
>
> <code>
> This is a test page.
> If web2py implement a plugin system, you should see a form to post a comment:
>
> {{load 'mypap/plugin_comments/form_comment'}}
> </code>
>
> So we only need to change gluon/template.py to:
> - when it finds "{{load 'a/b/c'}}" it does:
> 1- Copy code of function 'c' (controller 'b.py', app 'a') to some_var;
> 2- Add do some_var the code: "bla = function_c()"
> 3- Add do some_var the code: 'result = parse_template"("%s",
> path=../applications/%s/views/)' % (bla, a)
> 4- Add the content of some_var to code that will be executed in
> view (that code that have a lot of 'response.write')
> 5- So no we have the result we expect.
>
> It should be useful to other things too, like create some 'modules' of
> apps (we can create modules and should not create plugins for
> optimization) and to be an easy way to embed some actions/views in
> other pages.
>
> What do you think?
> I like this feature and think it should be implemented even it is not
> by default as plugin system - but I think if we use it in plugin
> system we will be creating apps with a more unobstructive and
> optimized code (for app, for browser/javascript and mainly for web
> server).
>
> We must learn more about plugin systems (with wordpress, for example)
> before posting this as stable.
>
> --
> Álvaro Justen
> Peta5 - Telecomunicações e Software Livre
> 21 3021-6001 / 9898-0141
> http://www.peta5.com.br/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
