[drupal-devel] Page layout workflow mockup
I've finally converted my original notebook drawings into a graphical workflow for review. You can download the full version here (30K): http://photos4.flickr.com/6944826_90af237c99_o.png and then add comments to its Flickr page: http://www.flickr.com/photos/factoryjoe/6944826/in/pool-drupal/ Note that the functionality I'm looking to create would allow you to layout out individual pages, which could double as section homepages or a site's homepage. Additionally, just about everything we need to put this together exists today; I've just organized it in such a way that I think is fairly simple to generate good results with minimal effort. Hopefully the various layout module efforts going on right now could benefit from my suggested 3 step approach. Chris
Hi, Can we not get a common Drupal-Image repository (site) somwhere? I find Flickr very annoying, with its Flash that makes my browser crash somethimes, and its odd login systems. No, I do use it sometimes, but am no fan of it at all. An was it not about eating own dogfood? But in the meantime: Chris, why can't you just use attachments to issues on drupal.org? Bèr Op zondag 20 maart 2005 23:06, schreef Chris Messina:
I've finally converted my original notebook drawings into a graphical workflow for review.
You can download the full version here (30K): http://photos4.flickr.com/6944826_90af237c99_o.png
and then add comments to its Flickr page: http://www.flickr.com/photos/factoryjoe/6944826/in/pool-drupal/
Note that the functionality I'm looking to create would allow you to layout out individual pages, which could double as section homepages or a site's homepage. Additionally, just about everything we need to put this together exists today; I've just organized it in such a way that I think is fairly simple to generate good results with minimal effort.
Hopefully the various layout module efforts going on right now could benefit from my suggested 3 step approach.
Chris Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Sorry about that! Guess I should go post a forum topic about this. I don't really know how I should cross-post these kinds of mockups since they involve so many different parties. For me it's of course most convenient to get all the comments in one place (hence my Flickr account) but I also realize that that's not optimal for everyone else. One of the things that I would like to build soon is a Flickr-like module for Drupal that allows for annotations on images but otherwise treats the image like a node so that I can get comments on it and whatnot. I also realize that I'm not using Flickr as it was intended per se, but there's nothing else out there that meets my needs so far. Chris On Mon, 21 Mar 2005 00:04:42 +0100, Bèr Kessels <berdrupal@tiscali.be> wrote:
Hi,
Can we not get a common Drupal-Image repository (site) somwhere? I find Flickr very annoying, with its Flash that makes my browser crash somethimes, and its odd login systems. No, I do use it sometimes, but am no fan of it at all. An was it not about eating own dogfood?
But in the meantime: Chris, why can't you just use attachments to issues on drupal.org?
Bèr
Op zondag 20 maart 2005 23:06, schreef Chris Messina:
I've finally converted my original notebook drawings into a graphical workflow for review.
You can download the full version here (30K): http://photos4.flickr.com/6944826_90af237c99_o.png
and then add comments to its Flickr page: http://www.flickr.com/photos/factoryjoe/6944826/in/pool-drupal/
Note that the functionality I'm looking to create would allow you to layout out individual pages, which could double as section homepages or a site's homepage. Additionally, just about everything we need to put this together exists today; I've just organized it in such a way that I think is fairly simple to generate good results with minimal effort.
Hopefully the various layout module efforts going on right now could benefit from my suggested 3 step approach.
Chris Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
On 20 Mar 2005, at 23:06, Chris Messina wrote:
I've finally converted my original notebook drawings into a graphical workflow for review.
In two words: it rocks. -- Dries Buytaert :: http://www.buytaert.net/
I like this one. I have an idea which would help implementing this. There are a lot of functions in Drupal which ends with print theme('page', $output); These shall be changed to return $output; and menu_execute_active_handler should be changed, too: - call_user_func_array($menu['items'][$mid]['callback'], $arguments); - return MENU_FOUND; + return call_user_func_array($menu['items'][$mid]['callback'], $arguments); and then index.php shall have a default clause to print theme('page', $status); -- well, let's rename $status to $return. After this you may call a page function via module_invoke and put it's output into a block. Regards NK
I have an idea which would help implementing this. There are a lot of functions in Drupal which ends with print theme('page', $output);
These shall be changed to return $output; and menu_execute_active_handler should be changed, too:
- call_user_func_array($menu['items'][$mid]['callback'], $arguments); - return MENU_FOUND; + return call_user_func_array($menu['items'][$mid]['callback'], $arguments);
and then index.php shall have a default clause to print theme('page', $status); -- well, let's rename $status to $return.
After this you may call a page function via module_invoke and put it's output into a block.
An excellent idea. It is very annoying that many functions do their own printing. Makes it hard to reuse the content, as you noted.
On 21 Mar 2005, at 5:11 PM, Moshe Weitzman wrote:
An excellent idea. It is very annoying that many functions do their own printing. Makes it hard to reuse the content, as you noted.
Only functions that print theme('page') should print. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
....
- call_user_func_array($menu['items'][$mid]['callback'], $arguments); - return MENU_FOUND; + return call_user_func_array($menu['items'][$mid]['callback'], $arguments);
and then index.php shall have a default clause to print theme('page', $status); -- well, let's rename $status to $return.
After this you may call a page function via module_invoke and put it's output into a block. +1 for this one
Op maandag 21 maart 2005 16:09, schreef Karoly Negyesi:
I like this one.
I have an idea which would help implementing this. There are a lot of functions in Drupal which ends with print theme('page', $output);
These shall be changed to return $output; and menu_execute_active_handler should be changed, too:
- call_user_func_array($menu['items'][$mid]['callback'], $arguments); - return MENU_FOUND; + return call_user_func_array($menu['items'][$mid]['callback'], $arguments);
and then index.php shall have a default clause to print theme('page', $status); -- well, let's rename $status to $return.
After this you may call a page function via module_invoke and put it's output into a block.
In a nuthsell: we go back to a pull system (every second release we seem to want to change push vs pull ;)), not? Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
On 21 Mar 2005, at 6:41 PM, Bèr Kessels wrote:
In a nuthsell: we go back to a pull system (every second release we seem to want to change push vs pull ;)), not?
Back to a pull system ? When were we ever a pull system? I think both approaches have benefits, but I can not see how (for instance) xtemplate will be able to implement pull based templates. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Op maandag 21 maart 2005 19:15, schreef Adrian Rossouw:
When were we ever a pull system? Sorry, I meant to say: back to that endless discussion about push vs pull system. We had some parts that were pulling conentent in the past, though. Allthough I cannot remember where an how exactly.
I think both approaches have benefits, but I can not see how (for instance) xtemplate will be able to implement pull based templates. Nop, My comment was a bit cynical. I like the ability of themes doing their stuff where they watn to (pull), but I would not want to be forced to do this. Hence a phphtemplate is a nice hybrid solution. IMO we should keep it like that.
Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
I have an idea which would help implementing this. There are a lot of functions in Drupal which ends with print theme('page', $output);
These shall be changed to return $output; and menu_execute_active_handler should be changed, too:
- call_user_func_array($menu['items'][$mid]['callback'], $arguments); - return MENU_FOUND; + return call_user_func_array($menu['items'][$mid]['callback'], $arguments);
and then index.php shall have a default clause to print theme('page', $status); -- well, let's rename $status to $return.
Won't this mess up XML feeds or the printer-friendly book output? Steven Wittens
On Mar 21, 2005, at 12:01 PM, Steven Wittens wrote:
I have an idea which would help implementing this. There are a lot of functions in Drupal which ends with print theme('page', $output);
These shall be changed to return $output; and menu_execute_active_handler should be changed, too:
- call_user_func_array($menu['items'][$mid]['callback'], $arguments); - return MENU_FOUND; + return call_user_func_array($menu['items'][$mid]['callback'], $arguments);
and then index.php shall have a default clause to print theme('page', $status); -- well, let's rename $status to $return.
Won't this mess up XML feeds or the printer-friendly book output?
I have similar concerns. These and some other examples of pages do not use theme('page'), so it must be possible for a menu callback to output without that wrapper. This can probably be managed with special-casing "return NULL;" to not pipe output through theme('page'), as suggested by Karoly. To make this change, you also have to police the entire code base for the many uses of drupal_set_title(), menu_set_location(), etc. At the moment all menu callbacks can assume that they are in charge of the entire page, and many use the above functions and others which would be detrimental to using the output in other contexts. One possible benefit of such a huge refactoring would be the ability to grab smaller pieces of a page outside of the page context somehow, for use in the Ajax stuff I'm playing with. (If you're interested, play with the table sorting widgets at http://jonbob.drupaldevs.org/api/head/group) -- Jonathan Chaffer Applications Developer, structure:interactive (616) 364-7423 http://www.structureinteractive.com/
I have similar concerns. These and some other examples of pages do not use theme('page'), so it must be possible for a menu callback to output without that wrapper. This can probably be managed with special-casing "return NULL;" to not pipe output through theme('page'), as suggested by Karoly.
right - problem solved.
To make this change, you also have to police the entire code base for the many uses of drupal_set_title(), menu_set_location(), etc. At the moment all menu callbacks can assume that they are in charge of the entire page, and many use the above functions and others which would be detrimental to using the output in other contexts.
again, not a big deal IMO. The callign code can always set the title as it wishes. It doesn't matter if the original page function had a title/breadcrumb or not. This is minor.
One possible benefit of such a huge refactoring would be the ability to grab smaller pieces of a page outside of the page context somehow, for use in the Ajax stuff I'm playing with. (If you're interested, play with the table sorting widgets at http://jonbob.drupaldevs.org/api/head/group)
Huge benefit! Love the demo. The code is squeeky clean. That drupal.js file is stunning in its simplicity and usefulness. PS: lets stay on topic here. Karoly's suggestion has nothing to do with changes to themes.
On Monday 21 March 2005 18.15, Gabor Hojtsy wrote:
Won't this mess up XML feeds or the printer-friendly book output?
Plus image generation and private file retrieval (ie. anything going through Drupal which is not going to be a Drupal page after all).
Let me quote myself: "There are a lot of functions in Drupal which ends with print theme('page', $output); these shall be changed to return $output;" Those functions Steven and Goba are talking of are not ending with a print theme... so I won't change them. Simply, there won't be a return value. ATM, I am not interested in these -- I only want to put pages' contents into blocks. The only change necessary to accomodate these problems is that the proposed default clause in index.php must be if(!empty($return)) print theme('page', $return); and we're done. Regards NK
On 21 Mar 2005, at 16:09, Karoly Negyesi wrote:
I like this one.
I have an idea which would help implementing this. There are a lot of functions in Drupal which ends with print theme('page', $output);
These shall be changed to return $output; and menu_execute_active_handler should be changed, too:
- call_user_func_array($menu['items'][$mid]['callback'], $arguments); - return MENU_FOUND; + return call_user_func_array($menu['items'][$mid]['callback'], $arguments);
and then index.php shall have a default clause to print theme('page', $status); -- well, let's rename $status to $return.
After this you may call a page function via module_invoke and put it's output into a block.
I don't understand your last sentence. Mind to elaborate on that? As far as I can see, the suggested approach might make the code slightly smaller (not in terms of lines, but in terms of the number of characters/line). I fail to see how this would help implement Chris' proposal. -- Dries Buytaert :: http://www.buytaert.net/
After this you may call a page function via module_invoke and put it's output into a block.
I don't understand your last sentence. Mind to elaborate on that? I fail to see how this would help implement Chris' proposal.
Well, maybe this is a usage of Chris' proposal and not an implementation but the line is not really sharp IMHO. For eg. there has been several requests for multiple nodes on a page -- that's what I thought of initially, but several anything on a page is possible. Regads ChX
It does seem like the approach I've mocked up blurs the boundaries between push and pull slightly, since you would essentially be choosing what blocks of micro-content you want to output on your page and in what region they would be output to. Please note that in my mockup, I was trying to map people's geometric understanding of a "page" as opposed Drupal's. This means of course that the XHTML that gets output for each "region" would simply be contained in a div: <div class="region" id="region-a"> ...output selected micro-content here </div> and so on. I'm not sure how Karoly's suggestions, which sound similar to his suggestion to put the page content into an array, help with this cause. That's not to say that his ideas wouldn't help, I frankly am not a developer enough (yet!) to comprehend his proposal. If I were to implement this today, I would end up with a pure PHP theme, which seems more like the "pull" model. Obviously going off in that direction doesn't solve the problem, so we need to look at what I can do with a custom PHP theme that I can't do with PHPTemplate or with writing a custom module. The answer to that, for me anyway, is not clear. What I do know, though, is that the primary focus of this discussion should be on how we can arbitrarily pull in micro-content blocks, leveraging the block system that already exists. Essentially, I'm looking to invoke the various block calls that already exist in modules to dump content into a page. I don't know how this works in practice, but that's how I was imagining this working when I drew up my workflow. Chris On Tue, 22 Mar 2005 12:29:32 +0100, Karoly Negyesi <karoly@negyesi.net> wrote:
After this you may call a page function via module_invoke and put it's output into a block.
I don't understand your last sentence. Mind to elaborate on that? I fail to see how this would help implement Chris' proposal.
Well, maybe this is a usage of Chris' proposal and not an implementation but the line is not really sharp IMHO. For eg. there has been several requests for multiple nodes on a page -- that's what I thought of initially, but several anything on a page is possible.
Regads
ChX
On 22 Mar 2005, at 18:51, Chris Messina wrote:
What I do know, though, is that the primary focus of this discussion should be on how we can arbitrarily pull in micro-content blocks, leveraging the block system that already exists. Essentially, I'm looking to invoke the various block calls that already exist in modules to dump content into a page. I don't know how this works in practice, but that's how I was imagining this working when I drew up my workflow.
I can understand the workflow, and I could (help) translate it into an implementation. What holds me back is not the workflow nor the concept, but the integration of what would be the corresponding configuration screen(s). Where do you envision these settings to live and how/where/when would an administrator use these? I would be helpful if you could take your workflow mockup one step further. -- Dries Buytaert :: http://www.buytaert.net/
I agree. There are quite a few open questions about this, which were hashed out in #civicspace yesterday. I can't say that answers were discovered, but some of the stickier problems with this idea and how the theme and node system relate to one another were raised. I will try and flesh this out some more this week... any other ideas/suggestions would be welcome. Chris On Wed, 23 Mar 2005 18:37:52 +0100, Dries Buytaert <dries@buytaert.net> wrote:
On 22 Mar 2005, at 18:51, Chris Messina wrote:
What I do know, though, is that the primary focus of this discussion should be on how we can arbitrarily pull in micro-content blocks, leveraging the block system that already exists. Essentially, I'm looking to invoke the various block calls that already exist in modules to dump content into a page. I don't know how this works in practice, but that's how I was imagining this working when I drew up my workflow.
I can understand the workflow, and I could (help) translate it into an implementation. What holds me back is not the workflow nor the concept, but the integration of what would be the corresponding configuration screen(s). Where do you envision these settings to live and how/where/when would an administrator use these? I would be helpful if you could take your workflow mockup one step further.
-- Dries Buytaert :: http://www.buytaert.net/
participants (10)
-
Adrian Rossouw -
Bèr Kessels -
Chris Messina -
Dries Buytaert -
Gabor Hojtsy -
Jonathan Chaffer -
Karoly Negyesi -
Moshe Weitzman -
Steven Wittens -
Vladimir Zlatanov