Requesting feedback for new idea: "Designer Page List"

Permalink 4 users found helpful
Customizing the page list block template is cool and all, but for custom-designed sites I often find myself building little custom page list blocks that don't have any edit options. I find these one-off blocks much easier for clients to manage (because there is nothing to manage). Also, this allows me to utilize custom attributes for filtering (I looked into adding custom attribute filter to the built-in page list block, but based on what I've recently learned about the form/attribute helper, it won't be possible to do this in a clean and generic way that can plug into the existing page_list block).

So I'm thinking of making a code generator similar to Designer Content, where you configure your custom Page List block via the dashboard and it spits out the block type.

Here are my thoughts... please leave feedback if you have any suggestions, if you can think of additional options to include, or if you just want to say whether you think it would be useful or not...

----

The dashboard interface would have three sections for building the block:
1) Fields that are outputted for each page item inside the foreach loop
2) Filter options (which pages will be included in the page list)
3) Sorting and display options

1) Available fields to output per-page:
* Page Title (with or without link to page)
* Description (page property)
* Excerpt (like Page List Teasers... you can choose an entire area, just the 1st block in an area, or a max. # of characters from the first block in the area)
* Link to page (with either the url as the link text, or some static text of the designer's choosing... for example "READ MORE")
* Attribute value (and different options for different attribute types, for example an image type would let you set thumbnail width/height, a boolean type would let you set the text corresponding to TRUE versus FALSE, etc.)
* Publication Date (or last modified date)
* Author (username or full name / 1st name from profile)
* Comment count (w/ optional anchor link to guestbook block on page)

All output fields could have "wrapper HTML" around them just like Designer Content has for its fields

2) Filter Options:
* Page type
* Under specific page (either 1 level deep or infinite levels deep)
* Attribute match
* page author

3) Display options:
* Pagination (eventually this could be expanded into "infinite scroll" pagination as well as traditional 1 2 3 4 5 etc.)
* RSS Feed (with option to show content excerpts in the feed, like Page List Teasers)
* Max # of items to display (per page, if pagination is enabled)
* Hierarchical vs. flat list (to match sitemap structure, so the page list could be more like the autonav).
* Breakdown by category (for example, if there's a select-type attribute, then each attribute value could be a heading and pages having that value selection would be listed under the appropriate heading).
* Display a title for the whole block (not sure how useful this is... the title could just be part of the wrapper HTML?)

Interested to hear peoples' thoughts on this.

-Jordan

jordanlev
 
glockops replied on at Permalink Reply
glockops
I really like this idea.
When building the block, if the attributes could be included in a similar manner of how attributes are applied to pages that would be glorious. With a running list of all attributes on the left, click to include/customize on the right. That could work for both the filters and what is displayed.

My other suggestion would be to have a "Include parent page in list" option, since I find myself needing the parent + children for navigation, etc.

I also like the idea of being able to add a title to the block, in a manner like:
My Navigation
- Page 1
- Page 2
- etc.

I'd be happy to help.
jordanlev replied on at Permalink Reply
jordanlev
Hi Daniel,
Thanks for your feedback.

I don't think I'll be able to include the attributes in the same way as they're done in the page edit dialog. The problem is that there's no way to show saved attribute values that aren't attached to a page/user/file (in other words, I can present the attribute editing controls, but have no way to insert previously-saved values into them for when a user goes back to edit the filters). So instead I was thinking of not really having editable attribute filters at all, but instead let the site designer build these into the block itself (so the end-user would just have a page list block that always filters on a certain attribute, but they would not be able to modify the parameters of that filter).

Can you please explain in more detail the request for "include parent page in list" option? Not sure I understand this one (but it sounds like it might be cool).

Adding a title to a block is something I have seen a lot of people request in the past for the page list block, so I'll probably include this as an option.

Finally, what is your area of expertise in terms of being able to help? (Thanks for the offer, it's much appreciated).
glockops replied on at Permalink Reply
glockops
So I'm trying to think of all the times when I've either designed a custom template or heavily modified something like a page list.

A challenge I've had to overcome is the ability to sort a list by an attribute. Either you have to extend the page list or get creative with page names. For example, a directory of people (e.g. personnel directory), it would be amazing to be able to create those through a designer block. It would need to allow multi-sort by attribute (last name, first name) though.

Are you imagining the RSS feed to be customized similar to how the page list is? If so, will the RSS feed output be customizable through a view file? I'm thinking about the ability to change the order attributes are included for each, each statement. So if the RSS is not customizable, it would be nice to be able to manipulate the attribute order (drag & drop, etc).

Also, why I'm throwing features at the dart-board... being able to export a page list as CSV/Excel would be pretty sweet. But now we're talking about building page lists as admin tools rather than front-end navigation. Probably something that fits better as a dashboard page search addition.
jordanlev replied on at Permalink Reply
jordanlev
Sorting by an attribute sounds interesting. I've never needed to do this myself (I always tell clients to arrange the pages in the sitemap in the order they want them to appear in the list), but I could see how that might be useful if there are a ton of pages in a section.

RSS: I wasn't thinking about making this customizable, but that's another good idea (just allow designers to choose output fields like they will with the web front-end).

Export: Yeah... not so much into this idea. Especially for the first iteration -- it's usually better to keep things focused on a single use-case if possible.

Thanks again for the great feedback.

-Jordan
arcanepain replied on at Permalink Reply
arcanepain
All sounds great to me, Jordan! Just discovered your new Custom Contact Form in Github/on your blog and still reeling from how much hassle that's going to save me in terms of validation and customisation...not to mention the AJAX! Very nice.

Yep...the Page List is one thing i'm getting pretty fed up of hacking and rebuilding time and time again. I'm far too disorganised to stick to one common framework/boilerplate for it each time, so continually find myself rehashing bits and pieces of what i've done before, trying to figure out how I made it work, hitting the forums again, etc, etc... Real pain. Be nice to have a guy do it right and start me off on the right track each time (all accompanied by the awesome code commenting throughout)!

One thing i've found myself doing once or twice, and I don't think is mentioned in your feature listing, is a master/page-list 'read more' link.

Basically, instead of pagination, just a button/a link at the very end of the page list taking you to another page with the full page list / a page list that's more complete in terms of images, summaries, etc... If someone is interested in the pages i'm listing (filtered by page type, like blog posts, news, etc..., or an attribute, like is_featured, for example) then they can click through to a page with a more attractive, helpful, complete listing.

Useful if you don't want to fiddle with pagination and pagination query-strings on a page with a headed sidebar page listing or something.

Sort of like i've done here ('Click here for more accommodation options...', etc... where I didn't want to page inside the tabs, but also didn't want to load every possible page in the list from the get-go):
http://www.awtm.co.uk/destinations/australia/#/stay...

Cheers, Jordan...loving your work!
jordanlev replied on at Permalink Reply
jordanlev
@arcanepain,
Thanks for the feedback. Glad you found the boilerplate contact form useful -- yeah I got sick of re-creating those every time (and the "External Form" block is the stupidest thing in the world and I wish they'd take it out of the system... but I digress).

Anywho, I think I understand your suggestion, but I think I will hold off on that at least for the first phase. It's just not something I've ever needed, so I wonder how versatile / broadly useful it would be. I mean, it does sound like it would be cool, but I'll need to focus on a core set of features for the first round just so I have a chance of actually getting something out the door.

If/when I do get this thing out, feel free to remind me of this feature in case I forget... maybe it can get put in for a version 2 or something?

Thanks,
Jordan
ChrisH replied on at Permalink Reply
ChrisH
Glad to see you’re running with this Jordan. I’d be happy to collaborate and look at integrating the JOIN on custom attribute proof of concept I’m working on that we talked about.

A few technical questions:

1) Are you planning on working with the existing pagelist / databaseitemlist / itemlist classes or rolling your own?

So far it’s been easier to experiment with functionality that PageList doesn’t currently support by writing queries based on chunks of existing code but not making use of existing functions. There are obvious benefits (pagination, version checking, permissions) to using the existing functions but if you’d like this to be extendable into a full on query builder it may be better to keep it separate.

2) Are you planning on pulling custom attribute data from the attribute tables and/or the search index table?

3) Have you worked with Views in Drupal? You mention Fields, Filters and Sorting as three Dashboard sections that Designer PageList may include. Views divides functionality into similar sections. Views also divides output formatting for any given query into discrete “Displays”. This allows you to setup one query and format its output in different ways like varying HTML output or XML output.

C5 would benefit tremendously from a robust query builder and I want to do whatever I can to make it a reality.
JohntheFish replied on at Permalink Reply
JohntheFish
Wit one of the big areas of functionality of this being to filter & sort the pages, possibly with multiple attributes, maybe the solution could have wider use if it was structured as a series of building blocks.

a. A generic custom filter & sorter, with appropriate adaptive UI.

b. A generic list displayer, formatter, paginater.

(b) Is the less interesting because it is simply custom templates. Even so, a custom template builder would no doubt get widespread use. (a) Has potential for page lists. But may also be of use for lists of other things: users, products, files, events(on an implementation that is not page based).

A designer page list builder would then be an assembly of (a) and (b).
jordanlev replied on at Permalink Reply
jordanlev
@JohnTheFish,
I think I'm in a very different place than you in terms of architecture decisions :)
I have zero desire to make anything that generic or abstract. Not that I think it's a bad idea, it's just that I prefer to focus on a single use case and build that out (avoiding "architecture astronautism" -- seehttp://www.joelonsoftware.com/articles/fog0000000018.html... andhttp://www.joelonsoftware.com/items/2008/05/01.html... ).

I think that more generic solutions should arise from the repetition of specific solutions -- and so the specific solutions should come first. It's just the way I like to work and what motivates me to get things done; I'm not saying it's the one and only true way.

-Jordan
jordanlev replied on at Permalink Reply
jordanlev
@ChrisH, thanks.

1) I am definitely going to work with the existing pagelist class.

2) I only plan to use custom attributes in the way that the pagelist class lets you use them -- by using the filterBy() methods.

3) I worked with Drupal a few years ago. I could never quite wrap my head around how Drupal works... just wasn't my cup of tea (although I struggled through and did build a couple of fairly substantial sites with it... just hated every minute of it :)
So yes I have some experience with CCK/Views, but I am by no means an expert. I must politely disagree with you that C5 would benefit from a robust query builder... to me the thing that's great about C5 is that it has a "site-centric" or "page-centric" essence to it, which I find much easier to develop and design for, and also much easier for non-technical people to understand so they can edit their sites with more confidence. Concrete5 is not the perfect solution for every job, but for many many kinds of websites, I think its philosophy of focusing on pages as opposed to treating content as items in a database is a huge win and do not want to see it get more complicated. Just my opinion, though. I totally understand that other people will feel differently and they wouldn't be wrong to do so.
mkly replied on at Permalink Reply
mkly
The Fresh Prince strikes again!

I always just write my own Page Lists. The block is actually more confusing to me than just writing
$pl = new PageList();
$pl->filterByAttribute('foo', 'bar');
$pages = $pl->get(5, 0);
$this->set('pages', $pages);


Would be so nice to have a generator no matter what it is.
jordanlev replied on at Permalink Reply
jordanlev
Thanks jazz,
I agree with you -- I think it's so easy to write those once you know all the foibles (i.e. filtering on "select" attribute values) that I never felt the need for a generator. But now in hindsight it's such an obvious idea.
mkly replied on at Permalink Reply
mkly
If anything, and honestly anything is pretty great, just putting a really nice logic-less view with a comment field at the top of the view with all the values at the top would go a long way with the semi coding designer crowd which I think a lot falls in your stuff's sweat spot typically.

Something like
/**
 * Hey Mrs or Mr Designer, here are the values you can work with
 * $pages - This is an array of pages you can show.
 * You would use this like foreach($pages as $page)
 * and then access attributes of that page with
 * echo $page->getAttribute('attribute_handle')
 * and I pulled out some specific value just for you!
 * $page->info->title is the title of the page
 * $page->info->description is the description of the page
 * etc
 */
<ul class="page-list">
<?php foreach($pages as $page): ?>
 <li>
   <h3><?= $page->info->title ?></h3>

It would be nice to see views in concrete5 start moving back to a little more view-ish.
jordanlev replied on at Permalink Reply
jordanlev
You mean like this:
https://github.com/concrete5/concrete5/blob/master/web/concrete/bloc...

...been in there since 5.5.0 I believe.

I totally agree that the default templates really need cleaning up. I submitted the autonav enhancement already:
https://github.com/concrete5/concrete5/pull/488...

...and hope to get to the form block eventually (putting in the templates from "Form Tableless Layout" and "Ajax Form" addons).

Search block would be nice too, but that's getting into diminishing returns.
mkly replied on at Permalink Reply
mkly
I mean like not this
// Prepare data for each page being listed...
$title = $th->entities($page->getCollectionName());
$url = $nh->getLinkToCollection($page);
$target = ($page->getCollectionPointerExternalLink() != '' && $page->openCollectionPointerExternalLinkInNewWindow()) ? '_blank' : $page->getAttribute('nav_target');
$target = empty($target) ? '_self' : $target;
$description = $page->getCollectionDescription();
$description = $controller->truncateSummaries ? $th->shorten($description, $controller->truncateChars) : $description;
$description = $th->entities($description)

I know I'm a hipster but that pretty much turns off the last 30% that wasn't already turned off because it's php and a cms.
jordanlev replied on at Permalink Reply
jordanlev
Hmm... I see your point. I'm not sure how much worse all that code inside the foreach loop is than having to explain "$page->info->title"... I guess it just moves it out of the way?
But I feel like for every 30% of people that are totally turned off by that, there are 10% of people that can see that code and have a better understanding of the system. Maybe :-/
mkly replied on at Permalink Reply
mkly
Cause its a view. With epic logic. But sure its ok but super un sexy.
jordanlev replied on at Permalink Reply
jordanlev
Yeah, you're right. It's just so much better than what came before. Maybe they'll accept my pull requests again in a year and I can improve this more at that time :)
adamjohnson replied on at Permalink Reply
adamjohnson
+1 for less logic, more view.
jordanlev replied on at Permalink Reply
jordanlev
You guys are totally right -- I will be sure to move as much logic as possible into the controller for this block-builder. Kind of good timing, as I'm getting the impression that submitting improvements to the core is not going to be a worthwhile investment of time moving forward... which means tools like this will be even more useful to us hipster markup snobs.

Will probably be a week or two before I have something ready.

Rock on Cleveland.
mkly replied on at Permalink Reply
mkly
While you're at it, rewrite all the other core blocks. They're hideous too. lol.

EDIT: I should disclaimer this was kind of a sarcastic comment.
jasteele12 replied on at Permalink Reply
jasteele12
Hi Jordan,

I like the ideas so far, and +1 for logic=controller. Also, please no target="_self" :)

If you want/need a guinea pig for testing, sign me up.

Thanks,

John
jordanlev replied on at Permalink Reply
jordanlev
What's the problem with target="_self"?
jasteele12 replied on at Permalink Reply
jasteele12
You mean besides the 15 wasted characters every link?

// $target = empty($target) ? '_self' : $target;
$target = empty($target) ? '' : ' target="'. $target. '"';
...
<a href="<?php echo $url. $target; ?>"><?php echo $title ?></a>
jordanlev replied on at Permalink Reply
jordanlev
Hmm... I guess 15 characters doesn't seem like a big deal to me.

If you're referring to the current page list template, the reason I did it that way is because I valued clarity of the markup over efficiency. For example, if you look closely at the code snippet you posted, you'll notice that there is an error in it. I've made a similar error many times in my own code and wanted to reduce the possibility of it happening to other people (especially designers, who aren't as code savvy as you or I). Having the markup always have a specific "slot" for the target makes the code easier to understand.
jasteele12 replied on at Permalink Reply
jasteele12
I guess that depends on how many links are in the list. I still don't see the point of outputting something that doesn't effect anything else other than increasing the output size.

That should teach me to post something untested, but I don't normally write PHP code in the forum post (easily caught with an editor/IDE syntax highlighting :)

<?php
error_reporting(-1);
ini_set('display_errors', 1);
$url = 'test-url';
$title = 'test title';
// $target = empty($target) ? '_self' : $target;
$target = empty($target) ? '' : ' target="'. $target. '"';
?>
...
<a href="<?php echo $url; ?>"<?php echo $target; ?>><?php echo $title; ?></a>


BTW, the commented line is from the concrete5 github repo...
jordanlev replied on at Permalink Reply
jordanlev
I understand where you're coming from. But my point is that it *does* effect something other than increasing output size... it makes the code easier to read and understand.

Reasonable people can disagree about where to draw that line between understandable code versus efficiency, so I'm not saying you're wrong... just pointing out that there is a reason to do it differently (even if you don't think that reason is very important).

And I'm the one who cleaned up the page list template to where it is now in github (it used to be a lot messier -- seehttps://github.com/concrete5/concrete5/blob/0842edd4889ccca9d2d0cb2c... ), so feel free to blame me for this travesty :)

All that being said, I will try to take this into account for the Page List Builder doohickey (since it won't be so much about having an editable template).
JohntheFish replied on at Permalink Reply
JohntheFish
A feature I would like with anything that gets listed.

All components of any list item are wrapped in something so I can treat them as one list item.

The current default view outputs

h3 /h3
div
p /p
/div

h3 /h3
div
p /p
/div

etc.

Lists are so much easier to work with if they are:

div
h3 /h3
div
p /p
/div
/div

div
h3 /h3
div
p /p
/div
/div

It makes it much easier to do stuff with each element in css or JavaScript without having to be diverted by the finer details of what it contains.
jordanlev replied on at Permalink Reply
jordanlev
Oh yeah, this will definitely be a feature... basically the same as how Designer Content handles "Wrapper HTML" now.
I mean, this can be done really easily by tweaking the existing Page List template markup... but making it even more explicit is a good thing.

Thanks.
jasteele12 replied on at Permalink Reply
jasteele12
Yeah, just thought I'd bring it up, since you will be *generating* the code. 100 pages x 15 characters (in single byte charsets) can add up.

XHTML strict doesn't allow the target attribute, in case someone has to comply with that (or accessibility).

Could have a switch for something like rel="new" and some jQuery in the builder:
<script type="text/javascript">
$(document).ready(function() {
  $('a[rel="new"]').click(function() { window.open(this.href); })
});
</script>


(maybe not the first version :)
jordanlev replied on at Permalink Reply
jordanlev
Hmm... I was not aware that the target attribute was invalid XHTML (kind of weird, since target="_blank" is the only consistent non-js way to open something in a new window).

That actually is a more important reason to me than saving the 15 characters.

Thanks for the enlightenment.

-Jordan
TheRealSean replied on at Permalink Reply
TheRealSean
For me when I use the Page List I almost always use attributes, so it would be nice to be able to add attributes to the view?

Something Like a custom attribute field with a select box to choose which attribute to include? (page_background is one I use 90%).
ie,
add custom attribute --> Page Background
--> Then adds the display "Page Background" in the page list controller
This may cause issues if a user removes a custom attribute at a later stage, or if a attribute is tied to a package that is later uninstalled?

I don't know if something like this is possible but could be a great help.(I think this is like you option 1 *(5th) but was not sure)

Some sort of ability to have a grid view would also be quite nice, (along with the ajax/paginated option)

When I use a thumbnail page list, I have added the ability to change the amount of entries that are displayed per line, whilst I am aware this is not used every time or by everyone it would be nice to have the ability to have edit a tags attribute.
ie every third Item I add class of large, or add a clearfix.

This is a longshot as I think this may be a very complicated piece of code to add? to a file that is dynamically generated.

Regards
Sean
jordanlev replied on at Permalink Reply
jordanlev
Hi Sean,
Thanks for the feedback. Yes, using attributes in the view is of the utmost importance (it is in fact the 5th item in part 1, as you guessed).

As for the "grid view", I think someone also mentioned this up above (can't find it now though)... but I could use some more clarification on this. As far as I can tell, implementing a grid view or multiple columns is just a matter of setting up each page item inside its own div, then putting a wrapper div around the whole thing and setting up the floats properly. Am I missing something (i.e. is there something special that could be an option to output into the html itself that would make this easier or work better in some other situation, other than the normal "Wrapper HTML" thing)?

-Jordan
TheRealSean replied on at Permalink Reply
TheRealSean
Thats pretty much how I set up a grid,

In my thumbnail Page list I allow the client to specify the amount of entries they would like per line, a product page usually

In my view I use the following, to deal with the width of the divs
$amountPerRow = ($controller->amountPerRow)?$controller->amountPerRow:1;
$entryWidth = 100/$amountPerRow;?>
<div class="entry-wrapper<?php echo(($i+1)%($controller->amountPerRow+1)==0)?" clearfix":""?>" style=" width:<?php echo $entryWidth;?>%">
<div class="entry">
<div class="image"><!-- css overflow hidden --!></div>
<!-- Page content in here --!>
</div>
</div>


This is probably a little over the top as normally I use 3/4/5 items per row so keep meaning to add less options via a selectbox and then switching the class, so I do not use a percent based value within the view.

I generally need to add a clearfix after said amount as the heights are not always the same, that then causes issues when using just float alone.

Though thinking about this now maybe just having some sort of grid/displayType variable set would be enough I could then do the relevant queries in the view.
Its a difficult call because I feel this may be one of those things that I deal with quite a lot but other do very differently. So I amended the default page list to allow for those options.

Maybe a grid option could allow a set number per line and then similar to the images allow for a height/width to be defined? for the containing divs?

Does that make sense? I'm trying to work through an example but can't think of a good solution to this that I could not deal with inside a custom template.

Regards
Sean
jordanlev replied on at Permalink Reply
jordanlev
Hi Sean,
So what is it exactly you'd want this hypothetical "Page List Block Maker" to do in order to support such a gridview (that couldn't already be achieved with html like you've shown)? Or are you just suggesting that it would generate that front-end code for you?
TheRealSean replied on at Permalink Reply
TheRealSean
I think I may be asking a little to much, I currently do a lot of this in the view but have modified the controller to allow me to pass through a few extra fields.

I saw this thread and jumped in with both feet, without fully thinking through what I would want from such a block.

With the page list I have modified moving some of the options into the controller,

In my instance its amount of columns per row and if the title is displayed above or below the thumbnail.
(I have been trying to provide the client with a way of editing this without needing to change the template)

I think this is may just be a specific case, though I am not to good at getting my thoughts on the screen :).

I'll try to go through and see if there is anything that could be added to a controller that would make it easier(and that could not be added within the view)
jordanlev replied on at Permalink Reply
jordanlev
No worries... that's what this discussion is for (to hash out ideas).

So, my thinking is that with this "Page List Block Creator", you'd create different PageList-esque blocks for each site, and each one would be tailored to that site's specific design needs. Because of this, you wouldn't need to provide the user with any kind of "number of columns" setting, because you as the designer would know how many columns you wanted based on the site layout... so you'd just "hard-code" the column gridview markup into the view.php file (like you're doing already).
I can see, however, that it might be useful to provide designers a way to do this more simply... but it would just be a mechanism to put a certain wrapper around every "nth" item... kind of like a "sporadic wrapper HTML" thing -- not something that the end-user (the person managing content on the site) would need to worry about.
TheRealSean replied on at Permalink Reply
TheRealSean
One other request and this is a minor one, would be to add the information of the parent into an object.

Within the autonav(not done this with the page list, so this could already exist)

I add pages to the footer under a particular page, when doing so you do no have access to the selected page. I do not do this often and can access it from the view, but would be nice to be able to access it as part of controller.

the concrete5.org site is a good example in the footer, the links that are within the columns, in order to work it out the selected page you have to grab the selected ID then set up the details from the view,
$title = Page::getByID($controller->displayPagesCID)->getCollectionName();


About <-- Selected Page ($controller->displayPagesCID)
Try it Out
For Developers
For Agencies
For Designers
For Anyone
Testimonials
Showcase
History
Our Philosophy
jordanlev replied on at Permalink Reply
jordanlev
I'm not understanding this one at all -- sorry :(
mkly replied on at Permalink Reply
mkly
I've been thinking about the limitations of no ActiveRecord/ORM with c5 views and how it's very difficult to have clean views without something like that. Then something hit me yesterday as goofy as that might be to clean up and prep views.

// Probably just stick this in controller.php
class PageSubModel extends Object {
  public $title;
  public $id;
  public function formattedTitle() {
    return Loader::helper('text')->shortenTextWord($this->title);
  }
}


And then in the controllers view() method load up that sub model and pass it to the view.
$pages = array();
foreach($page_list_pages as $page_list_page) {
  $pvm = new PageViewModel();
  $pvm->title = $page->getCollectionName();
  $pvm->id = $page->getCollectionID();
  $pages[] = $pvm;
}
$this->set('pages', $pages);


This way it would be obvious what stuff was included in the view and someone without a ton of php knowledge could hack on the PageSubModel to format etc stuff for the view while not turning views into spaghetti. Also help to keep the size down of the page list as a side effect.
jordanlev replied on at Permalink Reply
jordanlev
Design patterns? What design patterns? I kid, I kid.

If you look at the autonav block you'll see some historical evidence that this was tried there, but of course over time discipline was not maintained and a bunch of additional features were just added to the view instead of in the "view model" class where they probably belonged. Anywho...

Yes I absolutely will be doing something like this, where all of the data is prepped ahead of time (in the controller as everyone has rightly suggested in prior posts). I think it will just wind up being an array of "plain old data objects" though instead of methods (more straightforward for non-programmer designers that way methinks).
mkly replied on at Permalink Reply
mkly
Ya, I got the idea from your autonav view template building the navItem.

The pushing it into another object was just to give someone somewhere to look in a special little place away from the messy stuff but before the view. In case people wanted to extend the generated into something more. As is common with Designer Content it seems.

The computed values are just to throw one in there to lead them to the light. ;)

Figured it might lead to people copying it as blocks don't really have or need extra model code but controllers and views are getting a bit heavy because of it.