this is all good discussion, and interesting - but still
implementation level (e.g. explorative, and all at a very low level).
 That is ok, but before we get lost in the details, lets have a look
at some real workflow to develop.

1 - I want a way to guickly create a dummy layout so I can work out
what client / end user interaction should be, and perhaps discover
some needed data that wasn't obvious.
2 - this prototyping suggests that as I'm doing this, I want to
capture dummy behaviors, and template "plugins" could be helpful (e.g.
 flash a simple message "this will provide authenticated comment
entry").

If that plugin template is either directory based stuff, or a class -
it will provide defaults, remind me to override or remove optional
aspects.  In this way I can quickly capture many behaviors (many
templates), notes about basic intended aspects and not get mired down
in details of implementing some piece before I've captured all the
high level intdents.  The details may cause me to recognize an
emerging structure to my app, and cause me to refactor or remove some
components (so no use spennding much time developing them).

3 - perhaps 10% of these will be what Massimo intended - things you
use in other apps.  As I write more and more sites, I may notice
myself doing things repetatively, which will  cause me to rewrite some
old components more generally (btw, Massimo - the way you use the term
components I don't think is stndard in software eng.; google "software
components" and you should have a rich list)

At this point I will have my own components I reuse frequently, and
some of those I may polish up to share or sell (yet another refactor,
and consistent with incremental development).

My point is that - while the end objective of being able to use
components ('plugins') from others / the community is good, the bigger
goal is enabling rapid prototyping, encouraging normal incremental
evolution of components so that the "natural evolution" of the web2py
community is an ever growing reservoir of reusable pieces (as opposed
to accumulation of those only through intentional, mindful efforts).

- Yarko

On 10/1/09, Á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
-~----------~----~----~----~------~----~------~--~---

Reply via email to