On Wed, Oct 21, 2009 at 4:15 PM, mdipierro <mdipie...@cs.depaul.edu> wrote:
> > I do not understand. Models, Views and Controller are files. You can > encapsulate them in folders. How would you encapsulate them in > classes? > > Let me put is another way. > This discussion has kept a plugin implementation on hold for one year > because I think any other implementation is going to be more clunky. I > I think this has bogged down for one year (if that is true) because there is not a sufficiently crisp, well delineated definition of what you want. I think from the list of "many kinds" you sent a few minutes ago that to get to something crisp it may take more than one kind of system, each with rules that make it clear where each of the things from your wish list fits - that is, conceptual organization (e.g. some abstraction). > am happy to consider alternative solutions but I want to see a fully > working implementation by mid November so we can release plugin specs > by end the of the year. > > We should continue the discussion and you should continue try convince > me. I do not exclude I will be working on other implementations as > well (that why I do not promise backward compatibility on this yet). > > Massimo > > On Oct 21, 3:54 pm, Yarko Tymciurak <resultsinsoftw...@gmail.com> > wrote: > > On Wed, Oct 21, 2009 at 3:42 PM, mdipierro <mdipie...@cs.depaul.edu> > wrote: > > > > > On Oct 21, 3:01 pm, Yarko Tymciurak <resultsinsoftw...@gmail.com> > > > wrote: > > > > On Wed, Oct 21, 2009 at 2:50 PM, mdipierro <mdipie...@cs.depaul.edu> > > > 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 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 -~----------~----~----~----~------~----~------~--~---
