[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