On Wed, Oct 21, 2009 at 3:42 PM, mdipierro <[email protected]> wrote:
> > On Oct 21, 3:01 pm, Yarko Tymciurak <[email protected]> > wrote: > > On Wed, Oct 21, 2009 at 2:50 PM, mdipierro <[email protected]> > wrote: > > > > > As far as I am concerned think there are the only rules we need to > > > follow: > > > > > 1) a naming convention: > > > > > models/plugin_[name].py > > > controllers/plugin_[name].py > > > */plugin_[name]/* > > > > This convention is spaghetti source - it is crap; I do not like it in the > > least, and see absolutely no reason to even consider it. > > > > It will only lead to confusion, and novices learning to have to manage > all > > sorts of code they should not be looking at, knowing about the internal > > details (modularity - remember?!) - and if this is a teaching system, > even > > the more. > > > > I want to see you just DROP this convention. > > I'll repeat. It is crap. > > > > As Thadeus points out (and I only vaguely remember - it may need more > > discussion) - Mr. Freeze proposes something more appropriately > structured. > > > > Look at it again, more seriously. > > I did. Over and over. Let me explain why it is not crap. Think of a > matrix where the columns are models, views and controllers and the > rows are functional components like plugins. Then perhaps we need classes - since what you are saying is this structure (the row/column layout of web2py) is not able to cleanly encapsulate components / plugins for the programmer. You will have students - even maintainers - looking at applications, maintaining them, with all sorts of "plugin_xyz.py" files, some in controllers, some in... and they will change them - and you will remind them (because it is not well encapsulated) to ALSO change the associated models / views when they make a change.... AND to remember what they SHOULD NOT do.... AND..... AND..... I repeat - this is crap! ;-) Really (the smiley is not because I am kidding, but just that I am not giving way, but trying to add something to make this more friendly). It is crap because it will lead to this in the systems that go out, so one of two things are likely to occur ---- the "plugins" will be confusing, OR people will be tempted to change them in innapproriate ways, and it will devolve into nothing more than some fancy, enabled CUT-AND-PASTE opportunistic code-reuse system (not modular!). Trust me, if it smells like, and looks like ..... it probably is.... > Now we need to represent > this structure in a filesystem which has a tree like structure. No - YOUR solution has this constraint; I am saying look at the problem more, and reconsider your solution again... and again... and again... until it has the right shape. IF it suggests other things that need to be rewritten, and there is a cascade of that - while dissapointing, it may be a good thing (not a bad thing). > Again: > we are trying to represent a matrix as a tree. You want to do it by > row (one folder for each plugin and models/views/controllers > subfolders for each plugin). I want to represent it by column (top > level models/views/controllers and files of subfolders for each plugin > within each top level folder). Why I like the second better? Because > web2py already has that structure and in fact we have that already > without changing one line in web2py. > You are stuck in the depths of your solution here, so these arguments only apply there... I would like to see you get out of solution mode for a few minutes, and take a 50,000 meter view for a bit before you go back down to that level... > In order to take the other approach (the one you suggest) you would > have to represent some parts of the matrix by column (those that do > not belong to plugins) and some by row (those that belong to plugin) > and this would result in real spagetti code in the implementation and > it would constitue a major web2py rewrite. In which order should the > folders be looked up? In which order should models be executed? > > From a logical point of view plugins can be managed as subfolders and > that is what admin already does. > That is deployment - what about from the developer's perspective - what are the implications of this mess there?! Ach! - Yarko > > > > 2) models/plugin_[name].py can assume ONLY db, auth, crud, T > > > > auth, crud, T are gluon defined; that's ok. > > > > db is an application level variable, so that seems potentially > problematic, > > an assumption - this either needs to be NOT shared, or a way for the > > application to configure it for plugins is needed. > > > > > 3) models/plugin_[name].py should define only one global object > > > > > plugin_[name]=dict() > > > > Ugh! > > > > Well, this is ONE way to do plugin registration so the system know what > is > > there. It's uglly, and brut force. I don't even want to critique it > > because, as I've said before, the IMPORTANT point is: > > > > - The running app needs a way to discover what plugins are available, > and > > there must be a way for the plugin to somehow registrer it's presence. > > > > Now: WHAT are the important things an app / web2py instance must know > > about the plugin? > > > > - version? > > - name? > > - is it using / expecting app db connection? > > - is it creating own db connecntion? > > > > We should make a big list, and narrow it down to reasonable things later. > > > > This has not been done, and is one reason why discovery (and associated > > problems because of that) doesnt' yet exist. > > This is true but at this point I am just interested in making sure > people can experiment with LOAD and make sure one plugin does not > interfere with another. What plugins should share is another story and > I am not sure I want to dictate that. I can think for example of two > different web2py CMSes that may want to use distinct sets of > incompatible plugins and I do not see a problem with that. > > I define "component" a LOADable action of a "plugin". > > Massimo > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
