Those book cost too much. We really need to resolve this over a beer.
is the only thing you are asking to keep plugins files under a separate folder? How would the plugin be able to override the layout.html? How would it be able to overwrite a module (for example a local customized version of simplejson)? modules have to be toplevel in site-packages (in our case in app/ modules). Or consider a cms that has a file views/default/index.html. A plugin for the CMS should be able to override that file. Massimo On Oct 30, 12:41 am, Yarko Tymciurak <resultsinsoftw...@gmail.com> wrote: > or perhaps (better) Chapter 4 > inhttp://www.amazon.com/Principles-Design-Oxford-Advanced-Manufacturing... > > On Fri, Oct 30, 2009 at 12:39 AM, Yarko Tymciurak > <resultsinsoftw...@gmail.com> wrote: > > see, for example, sections 1.7.5 - 1.7.6 in > >http://www.amazon.com/Axiomatic-Design-Advances-Applications-Manufact... > > > On Fri, Oct 30, 2009 at 12:32 AM, Yarko Tymciurak < > > resultsinsoftw...@gmail.com> wrote: > > >> On Thu, Oct 29, 2009 at 11:21 PM, mdipierro <mdipie...@cs.depaul.edu>wrote: > > >>> Let's say we were to create a new folder called applications/*/ > >>> plugins, put stuff in there and modify web2py to handle the code in > >>> there in some special way. That the current mechanism in admin for > >>> packing, unpacking, deleting would still work. It is because plugins > >>> in a subfolder are simply more specialized plugins than the ones I am > >>> defining. > > >> I don't see this at all - I talk about implementing in a cleaner way the > >> SAME thing you are doing (no difference in behaviors, so not at all more > >> nor > >> less restrictive). > > >> It seems to me you are just talkking about ease of implementation, because > >> (?) you don't see value in not having the code all peppered in with > >> "normal" > >> application. > > >> As I look at your stuff on this, if you call it components, plugins, or > >> whatever - it's all the same - you can define how you want. > > >> It's just a matter of how well differentiated those component (or > >> "application subsets", as you call them - but, really, there is no need nor > >> benefit that I can see in defining new terms as we continue to talk about > >> the same things; actually, re-naming terms just for the sake of taking an > >> argumentative position, without any functional difference as far as I can > >> see I think is just consuming attention on non-useful things, and adds > >> unnecessary confusion. I would prefer to stick to one term - plug-ins - > >> and > >> discuss what affects how those work, how they are written, how they can > >> serve and be used within applcations, etc. All the other name-changing > >> and > >> implementation-details arguments get away from what I think is the > >> "interesting" part of the discussion: behaviors, and > >> encapsulation/differentiation (e.g. can I just "plug in" a scheduler in an > >> existing app, and what - if anything - do I need to get it to work? do I > >> need to install a scheduler - for example - plug-in once in my web2py, or > >> do > >> I _have_ to install it in every app (and why? what would be the benefit of > >> one way or the other?). > > >>> Let me play with with words: > > >> Please - let's not; no benefit to this as far as I can see.... > > >>> - What I call plugins should instead be called > >>> random_applications_subsets > > >> ...ach.... > > >>> - What you call plugins are special types of > >>> random_applications_subset that are somewhat isolated. > > >> ...ach.... yes, just call it plug-ins, and lets define those. What > >> motivates the change in name every time I ask about defining better what > >> you > >> are conceptualizing? No profit in this renaming, as either way the work of > >> thinking thru, being intentional (AND appropriately flexible), and defining > >> it CLEARLY is STILL the work at hand. Leave any tweaking of the name to > >> something more appropriate to later - call it a tiger AFTER is has been > >> clearly been made into whatever kind of animal it will turn out to > >> be!!!!!!!!! > > >> Ach! > > >>> What you call plugins does not exist yet. It needs to be created. > > >> .... defined, discussed, considered, and spelled out.... > > >>> I am > >>> taking a top-down approach instead of bottom-up approach > > >> No you are not - in fact, you are taking (as far as I can see) bottom up > >> (that is "build it, then call that the specification, if you like it) > >> approach ---- but in any case, this is a completely irrelevant discussion, > >> as doing both top-down and bottom-up to discover what is the most useful > >> shape is all part of the process of defining this.... > > >> So let's focus on behaviors and use (not names, implementation details, > >> and irrelevant development steps - top-down / bottom-up, after all, the > >> right mix of these is what creates a result; the result is not "top-down" > >> or "bottom-up" --- that kind of description makes no sense in describing a > >> behavior / result anyway! > > >>> because I am > >>> afraid of building something that turn out to be too restrictive. > > >> Fine - then talk about what degrees of freedom you want to ensure, and > >> this will help specify what ... does not yet seem to be crisply > >> specified.... > > >> What do you want to allow? What do you want to avoid restricting? > > >> I (for one) want to allow adding a calendar to my app, after the app has > >> been deployed, without needing to do anything / change anything in my app, > >> AND without the plug-in knowing anything about my app tables, or being > >> able > >> to directly touch my app data (THAT would TRULY be restrictive, and in > >> other > >> ways coupled unnecessarily, and .... I'll leave it to you to read all the > >> mathematical treatments of design coupling separately - e.g. Nham Suh's > >> treatmeint in "Axiomatic Design"... there are others, but that is a pretty > >> good description (even if it is gererally a weak guide to design). > > >>> When > >>> we have in trunk is a convention. > > >> Actually, it is very little more than that, and it seems grossly > >> under-defined (perhaps even "dangerously" so, in the sense that it allows > >> too many degrees of freedom, too many opportunities for coupling, too many > >> ways for it to become highly restrictive and decay into something not > >> useable). This is why I keep driving for better work on this; perhaps I > >> should just go off and write a few chapters to show examples of how to > >> design this, but I would not attend to that for many months, so instead I > >> try to encourage a little more to happen here..... > > >>> We can decide tomorrow not to follow > >>> it any more and remove the page in admin and no application would > >>> break. This is the beginning of a story that is yet to be written. > > >> Yes, and a dialog of pertinent discussions will help form the "story" > >> (e.g. the general architecture, shape that will be useful and sustainable > >> and flexible). > > >>> Before we write it we need to learn what others have done (Drupal for > >>> example). > > >> I found little useful in that architecture (other than defining an > >> interface for plugins to implement, and details of what is needed to > >> accomplish that in PHP - we need to just start w/ Python, and how to make > >> that work in web2py app structure... > > >>> I do not want to create a single plugin system (I do not believe in a > >>> one size fits all solution here) > > >> It seems to me your are mixing two different discussions here. It would > >> be good to separate them, or the discussion will necessarily be eternally > >> circular: > > >> - An abstraction that leads to a design / architecture (e.g. structure and > >> standard interfaces, and basic install / discover "conventions") is a > >> USEFUL "one size fits most" for a class of problems - this is, after all, > >> what architecture sets out to accomplish in ALL software engineering. > > >> - A PLUGIN is where the solutions (and the variability you desire, and the > >> "one size doesn't fit all" argument belongs) are designed. Not ALL > >> solutions will be appropriate to the "shape" of a plugin, but many - enough > >> that it is USEFUL to consider what shape will serve this class of solutions > >> well (that is, what architecture and conventions we "want" for a plugin > >> system) > > >>> but I want to give people like you > >>> the ability to create their own plugin system. > > >> *sigh* Well, there is a saying - the "great" thing about standards is > >> there are so many to choose from. > > >> Stated more clearely (since that is a rather sarcastic statement) - too > >> many standards errode the benefit of having ANY standard. > > >> A plugin system by which web2py authors can easily share (and "plug in") > >> pieces of solutions is desireable. > > >> It seems you need to make a decision: define a generally useful plugin > >> system for the community to accomplish this, which leaves appropriate > >> flexibility to maximize the range of solutions that this will be capable of > >> accomodating (or leave it to others to define, even if that might risk > >> resulting in "many standards to choose from" for web2py application and > >> plugin authors). > > >>> Some plugins may be > >>> specialized for a particular web2py CMS or other type of specialized > >>> type of app. > > >> Again - please PLEASE keep seaparate the particular plugin ("some > >> plugins") from the plugin system to hold / deploy / use those plugins > >> through. > > >> We have gone around and around on this discussion in circular, and mixed > >> discussions (e.g. implementation details; mixing the system from the > >> "range > >> of plugins", e.g. flexibility - these are separate concerns around the same > >> class of problems). > > >> Perhaps this really is beyond this kind of email discussion, where the > >> separation of concerns and considerations (and tasks) is not so clear to > >> everyone. > > >> Unnecessary coupling is "evil" and reduces flexibility, and getting to see > >> where it exists is much easier when concerns are separated, since a more > >> focused view appears as a result. > > >>> Now I am going to redefine: > > >>> plugin_0 := random_application_subset > >>> plugin_2 := what Mr Freeze calls a plugin > >>> plugin_3 := what Alvaro calls a plugin > >>> plugin_N := what Yarko calls a plugin > > >>> where _i indicates a higher level of abstraction/encapsulation of > >>> functionality. > > >> I see NO functional distinction between these - if you INSIST on this > >> proliferation of names ("this one is cheese; this one is swiss; this one > >> goes on a sandwich; this one goes on salad; provolone is for pasta;") > >> then I must ask - is there any PERTINENT and important distinction between > >> these, as far as discussion of the system for inserting / activating / > >> using > >> these is concerned? > > >> So far, I see NO need for distinction, rather a discussion of what is > >> COMMON among these, and what does that tell us that a plugin system - OUR > >> plugin system should need? > > >>> plugin_0 is simple. It is done. It is just a > >>> random_application_subset. The thing being plugged (plug) is a bunch > >>> of files. The thing it plugs into (socket) is an existing application, > >>> and it may very well break if socket and plug are not compatible. > > >> This is nothing more than code that is part of the application, and (if I > >> recall) it may be COUPLED in the application. There is little that speaks > >> of or attempts to enforce / encourage encapsulation - I would not even call > >> this a plugin; I see no real utility in this. > > >>> plugin_{i>0} are more complex because we need to define more clearly > >>> types of plugs and sockets. > > >> This is where discussion of the following sorts are appropriate and > >> necessary: > >> - SHOULD the plugin be able to modify application tables directly? > >> (NO!!!) > >> - HOW can the application DISCOVER the plugin? > >> - HOW will the plugin and application interact? (Thru plugin interfaces > >> that the plugin may optionally define? What do those need to be? How > >> flexible can they be? What are the REQUIRED implementations, e.g. > >> discovery and interface publication?) > >> - HOW will the plugins be installed, and instantiated (with gluon? what > >> is consequence of this? with requst, per app? with app instantiation? > >> How > >> should discovery work in each case?) > >> - Shall a plugin be PER web2py? PER application? Both options? What > >> are the benefits of each? > >> - How shall VERSIONS of plugin modules be dealt with? Can an application > >> require / restrain a version? (How can this be implemented?) > > >>> I am thinking about functions that need to > >>> dynamically create tables, insert records, change layout, add cron > >>> jobs, add internationalization strings, generate js, pieces of the app > >>> that need to communicate client-server, server-server, client-client > >>> (same client or different client). > > >>> I think this is going to take time. > > >> Agree.... For the questions I've suggested above where the answer is "Gee > >> - I am not sure, or I don't know" - a bottom-up (e.g. prototype it to find > >> out!) approach is appropriate. > > >>> Drupal provides a limited but > >>> successful approach that can help kick off a more concrete discussion. > > >> I looked at the Drupal docs today, and am not sure there is so much that > >> will be of help there; you may have a different conclusion. > > >> - Yarko > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
