[development] AB-Use revisions to replace previews

[Larry Garfield]

While I agree with Ber that we shouldn't force one workflow in core, we do 
need to establish a common data model for it.  Otherwise, there's no way for 
contrib modules to arbitrarily tie into it.  Right now, some contribs just 
store nid.  Technically that's wrong because then versioning doesn't work; 
they need nid and vid.  If we want "drafts in core", then we also have to 
have some mechanism for contribs to "just work" with whatever the draft 
mechanism is.  (A did column?  Just reusing vid?  Actions in core?  Something 
else?  I don't know.)  If we don't, you'll be able to save-as-draft the title 
and body and little else, which is rather pointless. :-)

On Sunday 10 June 2007, Bèr Kessels 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


-- 
Larry Garfield			AIM: LOLG42
larry at garfieldtech.com		ICQ: 6817012

"If nature has made any one thing less susceptible than all others of 
exclusive property, it is the action of the thinking power called an idea, 
which an individual may exclusively possess as long as he keeps it to 
himself; but the moment it is divulged, it forces itself into the possession 
of every one, and the receiver cannot dispossess himself of it."  -- Thomas 
Jefferson