The attached patch adds display parameters for views - page and block.
To do so, I have added 2 fields to the view_view database table, and of course 2 fields to the view settings form.
For parameters enter a comma-separated list of properties, each one like key=value or simple key if it's just a flag to enable, i.e. try out what you get with

cols=2,grid

Currently I am using the parameters
cols=[number] to set a number of columns, and
grid a simple flag to make a table grid instead of filling the nodes in divs for each column
Both are usable right now for view-types 'node-list' and 'teaser-list'.

The 'simple' column view also adds a small style-section to the html-header, so the display really show multiple columns ...

If you like the patch, I'll add the multi-column to list-view next, and I've also already been thinking about some other parameters we could make use of ...

Comments?

CommentFileSizeAuthor
#4 views-display-pars_0.patch10.04 KBray007
views-display-pars.patch8.86 KBray007

Comments

ray007’s picture

ray007 commented

I had been hoping for some feedback - positive or negative.

Bad time for reviewing or nobody interested in this feature?

merlinofchaos’s picture

merlinofchaos commented

I took a look at it, and left it so I could think it over.

I'm not really fond of putting in a field where you enter comma delimited fields. If you want that, you can do the same thing in the PHP Argument Code:

$view->whatever_fields['key'] = 'value';

It's slightly more confusing than the gadget you have, but the gadget you put on is used by some very small percentage of Views and will confuse everyone who doesn't need it. So I'm not in favor if this direction.

ray007’s picture

ray007 commented

Would 1 (or more) specifically described input fields more to your liking?
The main reason I was aiming for is of course the configurable number of columns, and my second goal was to have a nice field to define the theming function to use for every node in the view ...
Do you think there's some kind of patch I can come up with providing those features that you would like too?

ray007’s picture

ray007 commented
StatusFileSize
new views-display-pars_0.patch10.04 KB

Setting $view->someparameter may work when using the view from php-code, but for normal users that's not really an option I think.

The attached new patch provides display-parameters (currently 'cols' and 'grid') to be entered in separate fields, all tucked away in a collapsed fieldset.

Would it be acceptable this way?

ray007’s picture

ray007 commented

If nobody else wants this feature I'll go away and try to re-create it in an external module.

Please just tell me if you see this possibly being useful for the views-module itself and therefore a chance of the patch going in (with whatever modifications you would like me to do to make it acceptable), or if I should move the code somewhere else.

Thank you.

ray007’s picture

ray007 commented

I take the silence as a "no" then?

Any answer on the status would be nice, please.

moshe weitzman’s picture

moshe weitzman commented

personally, i do think this is useful. i think the lack of these settings makes style plugins more restrictive than needed ... earl should make the final call though.

merlinofchaos’s picture

merlinofchaos commented
Status: Needs review » Needs work

Unfortunately I think this new patch adds way too much specialized code to Views itself.

I really understand what you're trying to do here, and I'm a little uneasy just turning it down, but i think it's the wrong direction to go with the UI.

Here's a patch that I'll accept. It's...quite a bit harder, but it's the one that works.

Allow plugins to provide a chunk of a $form; use AJAX to add/remove that form chunk to the form whenever the plugin is changed. For those without javascript, it'll need a "change plugin" button that does the same thing. That's the direction this has to go, IMO, and it lets plugins have the kind of freedom they really need.

ray007’s picture

ray007 commented

I don't think something as basic as "we have parameters the view display functions can act upon" can work as plugins as the code is structured now. The adding of additional parameters might be nice to have in plugins, but how do the view display functions know which parameters there are (or should be) if we add them dynamically? And where in the database do we store the parameters?

In the longer run, it might make sense to try a separation between the data gathering core (which I hope will go into drupal core sometime) and the view edit gui. So we could also have different display configurations acting upon the the data sets ...

I'll think some more about it, maybe I just haven't yet understood how you envision the plugins in this case ...

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Version: 5.x-1.x-dev » 6.x-2.x-dev
Category: task » feature

Passing arbitrary parameters to views styles might be worth to re-consider for 6.x.

merlinofchaos’s picture

merlinofchaos commented

Views 2 pretty much has arbitrary paramters as plugins can design their own forms and data as they like.

merlinofchaos’s picture

merlinofchaos commented
Status: Needs work » Closed (won't fix)