I'm learning a lot with this discussion/lessons, anyone more? :-D Alex F El 21/10/2009 23:32, Yarko Tymciurak escribió: > > > On Wed, Oct 21, 2009 at 4:15 PM, mdipierro <mdipie...@cs.depaul.edu > <mailto: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 > <mailto:resultsinsoftw...@gmail.com>> > wrote: > > On Wed, Oct 21, 2009 at 3:42 PM, mdipierro > <mdipie...@cs.depaul.edu <mailto:mdipie...@cs.depaul.edu>> wrote: > > > > > On Oct 21, 3:01 pm, Yarko Tymciurak > <resultsinsoftw...@gmail.com <mailto:resultsinsoftw...@gmail.com>> > > > wrote: > > > > On Wed, Oct 21, 2009 at 2:50 PM, mdipierro > <mdipie...@cs.depaul.edu <mailto: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 > > > > >
-- 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 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 -~----------~----~----~----~------~----~------~--~---
