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? > Models (data layer), controllers (engineering rules or business rules), and views (presentation layer) are separation of concerns. You have them separated by directories / files. Classes (by definition) encapsulate behaviors (functions), and data. > 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 don't know what that means - I have heard you say / complain that "more code would have to change" - which is a sign of design coupling, so the natural coupling here is in the directory structure, used to hold all structure - it is showing its limitations perhaps. > I > 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. > You have this upside down, I think - I want to see the specs (what you want it to do, how you want it to behave) before you start showing me solutions for release. It is ok to prototype to flush out some aspects, some specs when you don't know - e.g. how would discovery work. But then, back to how this fits into the system - that look is needed. There is no "on hold" - if implementation were trivial, then you could just code it up. Since this needs thinking specification, LACK of that talk is what has put this on hold. It can go out in November. Then you will see in practice what it's limitations are, and iterate again in a year. Or you can think / specify a little more, have things work a little better, and cut the number of big iterations in 1/2 or less. Your choice. > > 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). > Experience will convince you. Or openness (willingness to try and see the other perspective). If you do not believe that having plugin_xxx.py files everywhere will create problems, then you will have to experience that. If the human side of this was not important, then the language (and aspects that get in your way) would not be important either. But is IS important. - Yarko > > 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 -~----------~----~----~----~------~----~------~--~---
