I have been playing with Editview, views and viewfields.
I've found some little "flaws" in the plan :-(... But I think we can make something really good :-)
I think the use case is something like this:
I have a content type, which, within it, wants to refer to a list of objects. The list of objects are themselves more complex than a single entry (otherwise, multi-value would do the trick!)
So, we need two content types, the parent content type, and a child content type.
So, a nice solution to this is to have a "viewfield" in the CCK of the parent content type that enables the list of children nodes to be displayed. We create a field, using the viewfield field type and give it a "default" of the view which shows the "children". This view is simple enough to set up so long as the child node has a node-reference that is set to the parent type. (We can of course control this viewfield, just as we do any other field we create, placing it anywhere in the output, etc)
But, when the parent type is edited, rather than seeing the view as an editable list of child-nodes (which would be ideal), we only see the name of the view (which is not something we should want to change)
So, the idea situation, I think, would be to use something like the editview module within the viewfield module such that when the parent type is being edited, we see (and can edit) all the items in the list too... and possibly add to them. (I would suggest that we do not need to edit each child item separately, but, we should arrange to simple process the whole form together - so it's not 100% editview, but anyway)
This merge of viewfield and editview would already be fantastic. However, then I thought about the functionality of editview itself.
editview currently provides a means of editing everything shown by the view, in this use case, and in the case shown on the editview pages, this would seem most appropriate when editing the parent class - everything becomes editable. But, when we are viewing an "view", then sometimes it would be nice to have some fields editable - and some fields NOT editable. For instance you may have a shopping cart where you want to be able to adjust the number of items for each line item in the cart, but you dont want to change the price, or the description.
In this case, the functionality of "edit view" really should be placed on each field in a view. What I'd like to see is that the view module provides an extra field attribute "editable" which, when selected uses the form API to get the content for that field, rather than the default.
This implies moving some of "editview" into the views module itself. But the result would be incredibly powerful in a lot of situations I think?
I would suggest that this could be done first, then the "edit" view could simply use it, with an override requesting that all fields are editable.
Lastly, we should take considerable care to ensure that permissions are respected on the various nodes being edited.
Comments
Looks like it might need
Looks like it might need some changes in CCK to make this "beautiful" too... either in cck, or in the core (:-( ) It looks to me like a node form is printed as a whole, and CCK additions likewise - we really need to have an "entry point" for each item in the CCK, so that we can call in for each item in the view separately. This would just mean a very small amount of code re-org and exposing some functions, but none-the-less, if I'm right, it makes implementing the module hard right now - which is maybe why editview chose to create it's own handlers to generate form elements, which to me is not ideal...
In order to allow the edit
In order to allow the edit "widgets" to be used, which is clearly whats needed - if somebody has taken the care to build a cck widget, and wants a field of that sort editable, then we must assume they want the widget used - then there needs to be a link into the cck module to use the widget.
Unfortunately, the CCK module is structured such that it goes through all the fields on a node, and runs the operations it needs to on all the widgets.
Hence, what it required is a small amount of re-factoring such that there is an entry point (from outside the content module) to run the operations required on a single field.
The re-factoring is not so hard, its JUST in:
_content_widget_invoke, (done)
These functions also deal with everything as a whole node, but we dont need to re-factor them, see below
_content_field_invoke,
_content_field_invoke_default,
_content_field_view
then the convenience functions need to be provided with a signature like content_(&$node, $field)
thats for:
content_load,
content_form, (done)
content_validate,
content_submit,
content_view,
(not the rest because they are to do with constructing a content node type I think))
But, of these, only content_form needs to be provided. For our task, we simply need a view with a number of parts of nodes on the view - some bits of which will be editable. So - once we have the form built, then when it comes to submitting etc, we can simply construct each node as a whole, and submit that through content_ in the normal way. We would not be submitting each field separately....
content view is the interesting thing.
Right now, if I understand correctly, the view module decides itself how to output data, would it be better to ask the content module to do this on its behalf?
inside views, I am only handling things for CCK objects (could extend it to all elements), and
- tables (done)
- lists
teasers and full nodes can wait I guess.
...
Yeah.
BTW, sometimes we want each of this "list of objects" to be composed of several fields (resembling a table). Multi-value field(s) won't work here either (because the 'delta' isn't synchronized).
Whatever you do, you should mimic the workflow done for "real" node forms. So that, for example, if I have a custom
hook_nodeapithat enhances a CCK form, I want it to work for these tabled forms too. All fields, CCK or not, should be present. Making sure that customhook_form_alter's won't terribly break is another story.(Another, minor, problem is what to do with timeouts. Saving several nodes at once is time consuming and the script might be terinated prematurely.)
For the meantime you can do without. Show the widget for every CCK field.
Views doesn't know about the internals of CCK. The admin tells Views what string to pass to CCK (the "formatter") and CCK does the rest.
I'm a little confused by
I'm a little confused by some of the things you wrote... but here goes :-)
I think on the list of objects, we are in agreements.
The "workflow" - I have TRIED to do this. It seems I need to call the validate, submit and save for each node - but if there are bug's in my code - it's around there... I have not covered the fuller "workflow" pattern of the nodes, so if people have review things set up (or even preview), then that is not covered. The idea of this thing is to make a "quick way" of updating SOME items on a selection (view list) of nodes... so, I am not sure that work-flows are helpful in this use case? If they are, I am afraid I may have to leave that to the interested reader :-(((((
for CCK or not fields, i.e. title, and body etc. I have not implemented those right now. I agree they should be done, but it is less clear to me how. For instance, in a list view, you probably want full text fields, in a table view, you might want input lines instead. Also, for me at least, I consider the "body" and "title" items in a node to be somewhat surplice to requirements, as I use CCK types for everything. They seem to be legacy from before the days of CCK.... So, I have left these items as "work to be done, by anybody who cares" :-)
and the hook form alters.... I have not done anything about this.... see work-flows :-(
In terms of the "editable" line, actually, this is the whole aim of what I want to do - so for me, it's the single crucial thing. The idea behind this is that it should allow you to select a few items that you want to update - while simply "viewing" others. So - in my case, I want to update a numeric field, while other descriptive fields are shown....
So - for me, this is really important to get in from the outset...
In terms of views no knowing about CCK, and admin telling the thing about the formatter.... I may have missed something there.... the way I have it, the view simply looks to see if the content type is listed in the info array, if it is, it calls across to the cck (using the one function I've put in place), and has the field (widget) generated....
...
It's probably enough to call node_validate() and node_save(). They call the rest. They expect the whole node. Why don't you do node_load(), overwrite the loaded fields with the ones from the tabled form, then proceed to do node_validate and node_save?
I think we can do without support for non-CCK fields. I don't think it's possible to support such fields anyway, because there's nothing that connects Views fields to form API elements.
OK.
Excellent, thats what I'm
Excellent, thats what I'm doing :-)
Almost done with the patches... just checking them now
It Works
I have now finished the first implementation.
Watch this space, I'll upload my patches for the views module and for the CCK module. Both are relatively small and isolated, but need a lot of scrutiny
I have uploaded these patches to the group page
http://groups.drupal.org/node/4891
but also created issues
http://drupal.org/node/156443 (for the views issues)
http://drupal.org/node/156444 (for the CCK issues)
(Each of these has the relevant patch for that module attached too)
Please use the group page from now on to add comments to this overall patch, and the issue pages to track issues WRT cck or views....
Cheers
Mark.
.....