I have been writing my own document, going through exactly what you are asking Yarko.
Hopefully I can post it later tonight, depending if baseball gets canceled or not! -Thadeus On Wed, Oct 21, 2009 at 4:50 PM, Yarko Tymciurak < resultsinsoftw...@gmail.com> wrote: > On Wed, Oct 21, 2009 at 4:45 PM, mdipierro <mdipie...@cs.depaul.edu>wrote: > >> >> We can go on and on. We need other people input on this. >> > > Do you want input, or relief? > > Do this for me - take your list of 13 things, and apply a category - what > kind of thing is it? on each, with the goal to get the 13 organized into no > more than 3 or 4. > > Then we can discuss if those 4 kinds of behaviors sound like plugin > behaviors or not. > > A starting point might be separating by something, anything that associates > things - e.g. those items where data is completely separate from app; those > where app database is shared; those things where app data tables are > modified (and I will prepare you for throwing those out completely when you > get to that ). > > If someone wants to give input in this context, that would be good. > > - Yarko > > >> >> >> 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 -~----------~----~----~----~------~----~------~--~---
