[development] AB-Use revisions to replace previews

Victor Kane victorkane at gmail.com
Sun Jun 10 13:56:54 UTC 2007


Certainly what you write is food for thought.

But, surely, a "save and continue" button could be placed in as an option?

Because the fundamental thing here, and this is not just a single
case, is for Drupal to continue to grow as a web application
framework. The absence of this option (even the frugal gmail interface
includes a "Save Now" button as I write this) keeps Drupal in the
"web" corner and doesn't allow it to be seen as a full fledged
"application".

Of course, modules such as autosave help here; but I do not think that
a save and continue button is a single case; certainly it should be an
option for all content types.

saludos,

Victor Kane
http://awebfactory.com.ar

On 6/10/07, Bèr Kessels <ber at webschuur.com> wrote:
> 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