Three things have conspired recently to make me revive this concept, which I haven't worked on for a few months.
1) Lisa asked What would you do with [grant] money?
2) Then she mentioned the Tearsheet idea to Amy Gahran of the Poynter Institute. (Who previously published an interview with NoD member and Knight recipient Benjamin Melançon).
3) Stijn sent me a very detailed outline for Tearsheet that I haven't reviewd yet. So I'm posting it here.
I've recently (re)read your posts about Tearsheet and web-to-print export
and think that this would indeed be the first step to make Drupal a
newspaper CMS that provides the basis for all content generation and
management, as opposed to just being the gateway to the web. I would like
to hear about what direction and form you'd like such a module to take, and
if maybe we could work out some consensus and collaborate. (I'm not a
first-rate programmer but I'd be willing to help with anything from
documentation and interfacing to filtering out silly bug and feature
requests.)My thoughts (which I already implemented in a quickly put-together module
for personal use) are these:* A newspaper will want to export XML by edition, or by part of an
edition, to give that to the layout staff. Ergo: export by a term in a
vocabulary.
* The XML would have to be updated automatically upon each change in a
relevant node (i.e. one that has the term or terms that were the basis for
initial creation of the XML)
* Ideally, creation and updating happen automatically according to
predefined settings.So what I did was actually quite simple:
* A nodeapi hook that acts upon save, insert and delete
* Within a vocabulary that one has specified beforehand (e.g. edition
number), it checks the term/tag of the node that's being
saved/inserted/deleted to. (e.g. edition 379)
* It pulls all the articles out of the database if they contain that term,
and have a workflow status that's not "Draft"
* With a pretty generic script, it puts that result in XML (fieldnames as
tags)
* It writes that XML to a specified directory
* Any further editing (exclude fields that you don't need, reorganize them
etc.) can be done with XSL(T), which InDesign CS3 supports but which can
also be achieved with just about any good xml editor.Of course, this is only the beginning, and there are many ways this could
be made more useful.But apparently you have something entirely different in mind for
Tearsheet; namely you want a module that constructs an xml based on a
search and an explicit save by the user of that result ("click to save").
My expertise is limited to my work at a student newspaper, so could you
explain what you deem to be the advantages of such a system? I dislike the
amount of user interaction that would then be needed to produce the XML,
and the fact that updates wouldn't be automatic.However, what I do like about your proposal is that users specify what
they want by a search. This search could then be saved and used as a preset
for further automatic XML generation à la my proposal.
I have not read the full details of this note. I did, a few months back, write a stub module for Tearsheet that used a plugin system for data exporting.
Also very interesting with regard to http://drupal.org/node/145551.
Comments
First review
We are describing two different workflows. Yours is tied to taxonomy; mine tied to the editor's desire to pick-and-choose items for export.
What we need to design is a module flexible enough to support multiple use cases. I wrote recently that I have written about a dozen Drupal modules. I have only released two because the others are workflow-dependant. I don't think that Tearsheet should dictate work habits; I think it should support them.
So if we combine the two approaches, I think we'll really have something.
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
--
http://ken.therickards.com/
Would views export as xml be useful here?
This thread could be the start of something that would have some applications here -- by leveraging views to select the nodes included in the xml, it becomes possible to become fully workflow independent --
Cheers,
Bill
FunnyMonkey
Tools for Teachers
FunnyMonkey
That looks promising. My
That looks promising. My sole objection to Views is the user interface. I'd like to be able to build something that page designers and line editors can understand. The current Views UI for defining a View and Filtering results is a bit daunting.
Victor proposed the concept of Views before (http://groups.drupal.org/node/3009#comment-8617).
See also http://drupal.org/node/114115.
I also like the ConTemplate approach to designing and storing output formats.
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
--
http://ken.therickards.com/
Views and UI
RE: "The current Views UI for defining a View and Filtering results is a bit daunting." -- absolutely -- whenever possible (and that has been just about all the time so far :) ) I don't have non-admins defining views -- the selection of content is done based on pre-defined criteria, and end users receive training on how to slot content into these pre-defined views (ie, the review queue, the "promote to front page" queue, etc) -- so, end users never see the view, and site admins are responsible for tweaking views in response to shifts in institutional needs --
WRT the UI for filtering: I've never gotten down to this, but I'd imagine that some good theming would work wonders in softening the UI of the stock filters --
The selection of nodes for export (and this assumes a clean UI to support the selection), and subsequently generating that format used by the export, is a thorny issue -- really, the UI is the trickiest part, because if the functionality isn't accessible it will not get used.
In some ways, I wonder about the possible connections between this and the SoC work you are currently mentoring -- if the results of a view could be filtered through a pluggable feed generator, that would allow a crazy amount of flexibility with regards to both generating lists of content and wrapping that content in the xml schema of choice --
I know the project includes a pluggable parser -- am I wrong in thinking that it also includes a pluggable feed creator? Or, in thinking this through, that could also be generated by a views include (like the ones that currently generate rss and OPML feeds off of views) --
Anyways -- I'm looking forward to seeing where this leads.
Cheers,
Bill
FunnyMonkey
Tools for Teachers
FunnyMonkey
views action
For at better Views UI you could take a look here: http://groups.drupal.org/node/4725
It's still a little tricky, but has a great potential. We are trying to implement it now as way to handle the vast amount of articles imported from the print edition:
It acts basically like the admin/content/node page - only it's a view and as such customizable.
Views it is?
Nikolai, that has promise. To be honest, I'm just now starting to use Views. Believe it or not, I don't really run any Drupal sites; I just build features for them. But I just launched a corporate intranet site that I manage.
So I think we want to layer a user-specific interface on top of Views. Originally I was against requiring Views, but it is almost core these days. I think we need a few elements:
Some of these, of course, may already exist.
It is the last concept that I think is really interesting. Take a look at ConTemplate and how it shows the node data available for theming. What I envision is an importer/parser that can take an XML spec (or DTD) and import the document tree. Then you could map Drupal objects to elements in the DTD. This would create an "output template" that your users could select.
I suspect that the Action module might be of use here, as might Import/Export API.
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
--
http://ken.therickards.com/
Back from my holiday
Some very interesting thoughts by all involved.
I hadn't thought about Views-as-xml but it sounds pretty good indeed. For me, using Views wouldn't be an issue because (as you can read in my mail to Ken) my exports are usually pretty predictable and standard. However, I don't know if the UI that Nikolai shows will be enough to easily make various unrelated exports. I also doubt if it's humanly possible to keep a simple newb-proof UI if things like Views arguments etc. need to be editable by users.
Amount of flexibility?
I don't know if anybody actually needs that amount of flexibility (I don't; don't know about Ken), but it's worth thinking about. Maybe we need more use cases?
A possible way out would be to use Views and shortcuts as Ken describes for exports that have some logic in them. I.e. everything from a given term, everything from the last month, etc. where the user can only edit some specifics not but the entire query ... and another system altogether for exports that have little or no logic behind them: select every article you want to export to a file, and when you've selected all of them, "click here" to export - a "shopping basket" system if you will. That is, of course, if people actually request the latter.
Shortcuts
About the "shortcuts": this is actually as easy as saving the current URL away, as Views arguments are part of the URL, and so are Views exposed filter options.