I read a lot of topics in this group, and all the questions you are discussing are good ones, I like it. But there is something I'm really missing, you talk a lot, and sometimes it's being hard to read all the posts within a single discussion. You are discussing heavy architectural choices here but you aren't drawing any diagrams, schemas, components driagrams or such.
The major downside here is that from a newcomer like me can hardly understand the whole point of all of this without a good synthesis or a good schema. In some of the issues, you are talking about complex behavior, such as configuration override by context, and such, but you do not draw it.
Is there comprehensive posts somewhere I'm missing about the whole design or do you try to think about each smallest idea without being able to draw the full picture/design? I'd say it lacks a "great architect" to see the whole problem from a wide angle, and that every single post here is becoming a battle by itself where the full Butler project should be one single problem from which should arize a more global schema.
It needs some synthesis for people to understand, really :)
EDIT: Finally found that the first post in the lowest place on the page was the synthesis, that's good, I'm going to read all of this. But the question remains that you never draw pictures to illustrate what you are saying?
Comments
I hope i can tell in nutshell
I hope i can tell in nutshell why butler would be important.
With this "technology" it would allow drupal to be more lightweight and more responsive as backend for example when whole bootstrap when it is used with json/xml-rpc or other tasks witch wouldn't require full bootstrap to be loaded and executed. And also even if more features are needed, often not all modules are not needed to be loaded as they could be loaded depended if we need them.
Crell kept excelent presentation about this on drupalcon cph but can't find it on internet anymore, maybe someone else can give a hand on this one ;)
I hope this helped anyone.
"no pictures"
Maybe we are all too lazy and don't want to fire up a graphics program.
Secondly, I don't know how many of the people writing here, and especially, how many of our readers, know how to produce and read these diagrams.
I for myself am supposed to know it I guess, but .. ehm .. don't ask me. I would probably make a decent one if I really want to, but it's by far not a routine task.
Do they have a "diagram culture" over at Zend? And does it work?
In fact, the whole IT field
In fact, the whole IT field has a diagram culture. The fact is, for three years using Drupal I never saw at least one, which is quite sad actually. Code is like music, conception is all about having a fresh mind and clean ideas. Don't forget that a good picture worth a thousand words, especially in a context where people speaks tens of different natural languages. I'm french, I can pretty clearly write and read english (at least enough for what I do), but this more like a chance than being natural. The whole idea between today's IT is drawing. It's about modelling, abstracting, representing and communicating. Drawing, even with no particular formalism remain the most powerful language for it. The whole OOP and design pattern stuff is about drawing clearly complex problem. Whatever is the problem you have, if you can synthesize it in one clean drawing, you will be able to resolve it in a clear, simple and elegant way. If you're way of designing software is writing a book, I'm afraid the only solutions you come to will be an encyclopedia in which every single word will be a complex materialized complex though.
It's not about drawing, or Zend, or nothing else, it's about simplicity, KISS principles and such.
Zend have a great design which is dividing problems in single and simple composants, for which drawings may not be necessary because they use the right words over their own problems They name things using the common today's IT language which is mainly composed by design patterns and component oriented paradigms for which thousands of diagrams already exists. So yes, it works pretty well indeed.
A good example is the drupal_static() function. It's name doesn't refer what it is, it is a basic implementation of the registry pattern. Because the name is wrong, it's usage is too, until you say it loudly so that people stops calling their registry data the name of callee function, which is quite dumb because it discourage people from using other's functions data, even within the same module namespace and cause some abnormalities such as duplicated in memory theme registry (bug for which I helped the guy whom found it resolving by sharing a common statically cached piece of data, e.g. using the registry as a registry).
Pierre.
For drupal_static() I have
For drupal_static() I have something interesting.
http://drupal.org/node/632434
And yep, drupal_static() is a global registry. I think that other function that I proposed over there is not, because you can only reset and don't have free access.
Whether a registry is good or bad (or when it is ok to have) is a different question. I prefer if components share only what they need to share.
My question was rather, if the guys at a forum at Zend comparable to this one upload diagrams en masse.
Good question I'm not that
Good question I'm not that into Zend to tell you (EDIT: meaning, I dont contribute to it).
At least they call a spade a spade (EDIT: Meaning, I have developed against ZF enough to know that).
EDIT: Your question was a good one, so I went searching a bit. In fact, in the zend community wiki, while browing I found a lot of diagrams at various places, such as in some component proposal, etc..
See http://framework.zend.com/wiki/display/ZFPROP/Home
Pierre.
I will work on turning the
I will work on turning the information found here into several diagrams. I think that would be really useful for others like me trying to understand the scope here.
I will work on turning the
EDIT: Oops double post.
Presentations
There actually have been a couple of pictures made, mostly as part of presentations I've given at DrupalCon SF, DrupalCon CPH, and just this week at DrupalCon Chicago. The first two are available online:
From SF:
http://www.garfieldtech.com/blog/drupalconsf (the Blocks TNG slides)
From CPH:
http://www.garfieldtech.com/blog/butler-slides
And my Core Conversation slides for Chicago aren't online yet but should be soon.
Sadly I don't know if CPH ever put my video online. If the Chicago Core Con session was recorded I will post a link to it as soon as I have it.
That said, it's true that there is not much of a "diagram culture" in Drupal. Drupal architecturally is very hard to diagram. That's not a good thing.
Thanks for the links.
Thanks for the links.
Pierre.