Hi Massimo,
For me, the framework level plugins aren't plugins for apps directly...
(as their name say) in the sense that are low level plugins to install
by a developer and only one time in your system (not one time for each
application). The example I wrote it's a valid example, ie. and
extension for the code editor, a new web analytics plugin for admin, or
a new coachDB connector, a memcached cache plugin, a plugin for events
model tasks, an extension to CRUD, etc. They are for all your web2py,
and don´t have to be packed with applications, but downloaded alongside
with your web2py, as you do now to use ssl, pygmets, or any egg you use
(like thadeus does with his blogetizor), and are meant to be helpers to
make the developer life easier and applications more powerful.
Applicacions plugins can be packed (or not) with your application, and
of course has as many copys as applications you have, and of course (I
think somebady complaint) you have to upgrade them (or not if you don't
need it) one by one if you are working in several projects at a time
(cause each one has his proper version and it's logical).
It's clear to me, that it has to be a good system process to 1) firstly:
check the dependencies and connections between plugins, and 2) secondly:
after that, check the order to execute them properly,
so if I have something like this:
plugin_most_active_users.requires=['comments-1.x.x', 'auth-2.x.x']
plugins['tag_cloud'].requires =['tags-1.2.x']
plugins['tags'].requires = ['full_text_search-0.x.x']
The system will complain If I try to install "tag_cloud" without the
last "tags-1.2.4" plugin, and after that it will try to load
full_text_search firstly, later tags-1.2.x, auth-2.x.x, and
comments-1.x.x and finally most_active_users and ta_cloud... (its a
simple example)
alex
El 12/03/2010 15:52, mdipierro escribió:
The problem with framework level plugins is that if you pack the app
and unpack somewhere else then it will not work without the "framework
level" plugin installed separately. I do not think that is something
to encourage. Moreover different apps may reply on different versions
of the plugin and/or need different configuration.
Anyway there are two things that can be done at framework level: 1)
put models in web2py/site-packages 2) framework level models can be
defined in modules and put there also; 3) framework level views and
static file can be stored in a new app designed at hoc for this
purpose and other app can use them too.
Massimo
On Mar 12, 8:36 am, Alex Fanjul<alex.fan...@gmail.com> wrote:
Just to clarify it:
Do we able to conservate my app (rewrited/extended) auth module/model,
working alongside "superAuth" thadeus plugin, discarding your framework
plugin and system Auth default one?
Alex
El 12/03/2010 15:31, Alex Fanjul escribi :
Ok Massimo,
I agree with you in it makes no sense to rewrite a lot of web2py code.
Apart from that argument in favor, there is another I don't know if it
would be satisfied right now with plugin_name.py convention:
-Imagine you write a *framework level plugin* to subsitute auths (or
whatever system feature) views/controllers/models.
-Imagine thadeusb write another *application level plugin* to do the
same called "superAuth"
-Imagine I write an application with an *only modules* extended auth
service with some more fields and stuffs.
Do we able to conservate my app rewrited/extended auth module/model
over "superAuth" thadeus plugin, discarting system default one?
Just thoughts,
Alex
El 12/03/2010 14:01, mdipierro escribi :
The location of plugins is not a backward compatibility issue. From
that point of view, we could relocate plugin files.
The reason I do not want to do is that it is an implementation issue
that requires rewriting a lot of web2py code (particularly for the
bytecode-compile functionality), that will make web2py slower, not
faster, and does not seem to add any new feature (except the
relocation itself).
The only argument I have heard in favor of relocation is in fact that
code will look cleaner with a new plugins location. I do not disagree
but to users of admin things will look exactly the same (because of
the logical location according to admin is already the one you
suggest), to users of the shell models would be scattered and it would
be more difficult to identify order of execution, and you will get a
little bit of cleanness is user code at the expense of lots of dirt in
web2py code (lots of if statements to find out what is where).
I will not do it. If somebody wants to write a fully working proof of
concept implementation to demonstrate that 1) it is not slower; 2) it
can be done without too much extra complexity in web2py source, I may
take the patch.
Massimo
On Mar 12, 4:39 am, Alex Fanjul<alex.fan...@gmail.com> wrote:
Hi Massimo,
I haven't said that plugins should have to depend on others, but they
should be able to access/play with others to make a trully plugins
central network, the dependencies are resoluble at highly level with an
exposed convention API like:
plugin_most_active_users.requires=['comments-1.x.x', 'auth-2.x.x']
plugins['tag_cloud'].requires =['tags-1.2.x']
Its only an idea.
The backward compatibility breaks with the heritance folder structure
(as I though you said), isn't it?
*App Level: (example: plugin for commets)*
web2py/applications/my_app/plugins/my_plugin/modules/module*.py
web2py/applications/my_app/plugins/my_plugin/views/views*.py
web2py/applications/my_app/plugins/my_plugin/controllers/controllers*.py
web2py/applications/my_app/plugins/my_plugin/static/statics*.jpg
*Framework Level (example: plugin for ckeditor Editor, or last Wes
James
coda helper)*
web2py/plugins/my_plugin/controllers/controllers*.py
web2py/plugins/my_plugin/views/views*.py
The way to ordering load is down-to-up I think, like kohana
does:http://docs.kohanaphp.com/general/modules,http://v3.kohanaphp.com/gui....
Also it's very important the hooks
<http://docs.kohanaphp.com/general/events> & events
<http://docs.kohanaphp.com/general/events> system, as both of you
(thadeus, Massimo) talked at the end of the chat:
There is no calling for new Cache system at all...just was an
example...
regards,
Alex
El 12/03/2010 5:26, mdipierro escribi :
I agree with most of what you say.
99.99% of apps use a single database and so will plugins. This is
because they needs auth to do anything meaningful.
I do not think it is a good idea to have plugins that depend on each
other. dependencies are a mess to manage. In any language and any OS I
ever used. plugins with dependencies are cause for trouble.
But I agree that we may build groups of plugins that cooperate for
some specific tasks (like share access to certain tables and or
certain web services). This will happen for plugins geared toward
specific types of apps so we should not over-engineer it now.
I do not think we need a 2.0 for those things that you asked. We will
get there in small steps and, at this point, I do not see why any of
those improvements should be inconsistent with backward compatibility.
What's your wish list for cache? I never heard anybody calling for a
new cache system.
Massimo
On Mar 11, 9:02 pm, Alex Fanjul<alex.fan...@gmail.com> wrote:
Very interesting and constructive IRC meeting, congrats to all. After
reading all text I have some comments:
- Most of the meeting (50% at least) was concerning about *how
many and
what databases should plugins have access to*...it seems the most
headache for all, BUT, I'm pretty sure that 99% of today real WEB
applications (and very complex ones) in world uses no more than 1
database: think of Magento's, Elgg's, Zimbra's, Active Collab's,
Twitter's, OpenBravo's, Wordpress's, Drupal's, etc. All of them
use only
ONE database (maybe clustered, spreaded, mirrored, etc. but ONE), and
many of them has very complex plugins systems. The "problem" here, is
that with web2py its very simple and easy to create a new
database: just
do "db=DAL(...)"... and many times we are even "confusing" (in the
right
sense) databases with tables... A game for us: Tell me more than 2
real
web applications using more than one database. A reflection: I
would be
very afraid if after installing 20 plugins (as I have in my latest
drupal installation) I bump into 20 (or 15 or 10 or even 5) new
databases in my phpmyadmin/pgadmin. Yea: be generic and assume all
posible cases... but....
I think Thadeusb was in the right direccion in some
comments...asumming
a worst case of ONE shared db for plugins. moreover this would
simplified things, right?
- "Turicas: should a plugin access other plugins' data?" -->
"thadeusb:
Turicas: I would think no, because a plugin should be self
contained."
In this case I disagree, the plugins -for sure- should be able to
access
to other plugins data/functions, because as centralplugins grow
up, many
of them will be based on others to not reinvent the wheel, so *we
will
need a strong convention in exposing API for functions, objects,
etc.*
(think of a "plugin_most_active_users" based on thadeus
"plugin_commets").
- Finally I believe that a "heritance folder convention" where you
can
override/extend parents functionality/skins/models like the great
kohana's plugin system (someone mentioned) is the best way to
achive a
"easy" and "comprensible" plugin system. Yes, that would suppose a
big
change and probably a backward compatible inflexion point, but as
Massimo said, talk me about functionallity not about implementation.
Concerning this, and to be honest I'm always thinking of a Massimo
annunce saying: "Web2py 2.0 Released: the new easier, faster and even
more powerful python web framework with new DAL, new Plugin
System, new
Cache System, new CSS/Form system, etc. (ops but without 1.x backwark
compatibility sorry)", but it's just a dream :-P
Is there any new IRC appointment planned?
Best regards,
Alex
PD: excuse me for my english (as always)
--
Alejandro Fanjul Fdez.
alex.fan...@gmail.comwww.mhproject.org
--
Alejandro Fanjul Fdez.
alex.fan...@gmail.comwww.mhproject.org
--
Alejandro Fanjul Fdez.
alex.fan...@gmail.comwww.mhproject.org
--
Alejandro Fanjul Fdez.
alex.fan...@gmail.com
www.mhproject.org
--
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web...@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.
