We can go on and on. We need other people input on this.
On Oct 21, 4:32 pm, Yarko Tymciurak <resultsinsoftw...@gmail.com> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
