[development] AB-Use revisions to replace previews

Bèr Kessels ber at webschuur.com
Sun Jun 10 13:14:17 UTC 2007


Hi,

On zondag 10 juni 2007, Victor Kane wrote:
> This is really necessary for many practical applications of Drupal.
> Please put yourselves in the place of end users.

Sure. But many don't need this exact workflow. Others don't need it at all. 
When Drupal harcodes such workflows, including things like "saving drafts" in 
its core, this is both annoying for developers and end users. 
* End-users that need some save draft, might find that the Drupal 
implementation is almost what they need, yet not exactly. Hence they might 
need it improved or altered. With something hardcoded this becomes very hard. 
Bad idea. 
* Developers that don't need this exact workflow, or need a far more advanced 
(Random example: Save to group Drafts, Save as private Draft etc) will need 
to spend a lot of time hacking the hardwired workflows out. Thereby breaking 
many contribs that, by that time, depend on that hardwired workflow, etc.

What I am trying to say, is that this whole conversation about abusing 
revisions to show previews forgets the very fact that Drupal is not just for 
you and your case. There are many cases. Many details that differ from site 
to site, and project to project. If we all needed the exact same website with 
the exact same behaviour, then we can think about hardwiring such behaviour 
in a core.

Therefore, lets simply keep this in our minds and lets not come up with nifty, 
detailed features for core. Save as Draft is a nice feature: but please 
propose this with the acitons/workflow project, or some other dedicated 
module. Using revisions for previews is a nice idea: but please instead 
rather discuss how to make previewing more modular, instead of proposing it 
as the one and only solution.

AFAIKS all we *really* need is a hook_nodeapi #preview, or better even, a form 
alter #preview (to extend this preview beyond merely nodes). Then, any module 
can make its previews. CCK can use this to pre-calculate the previews. 
comment.module to simply render the data with some extra metadata. Media 
modules (there is no module that does /proper/ file handling on previes 
around) to show the files inline etc. 

But even if above idea of a #preview is silly, the point is, that we should 
think beyond our own cases. It has been a good thing that core has less and 
less hardwired workflow thingies in, ever since 4.7. Lets not turn these 
improvements back by going wild on all sorts of preview features in core.

Regards, 
	Bèr Kessels
-- 
 Bèr Kessels			http://webschuur.com
 Webschuur.com			IM: ber at jabber.webschuur.com
 Voorstadslaan 211		skype: webschuur
 6541 SN Nijmegen		Nederland/Netherlands


More information about the development mailing list