#77 — Initiative Display and Ordering

Looking at the code, I'd like you to remove the InitiativeLink type if it is okay. We need to cut back on the different content types as it is. You can easily provide the desired functionality by just adding a link field to the initiative type. If a value is present, use the link. If not, use it like normal.

Also, any thoughts on how you were planning on handling the ordering of these things? I've got an idea on a couple ways it could be achieved.

Remember, this place can be used for planning and such so we can iron out ideas before they're implemented.

It'd sure be nice to have a trac for proposals, bug tracking, discussion and such. wink Kim :)

Yah, the easiest thing to do would be to use the already present ordering functionality in the folder_contents of the initiatives folder already created. Then there is nothing more to it really. Just take the first 5 published from the initiatives folder and be done with it. Too easy.

Just a suggestion, but you might want to limit the results for the initiatives. Unless you're assuming they'll delete old initiatives? It's just that you're waking up all initiative objects on every call. This could be heavy. You could add indexes to the catalog for those fields you need and get the brains from the catalog. That'd help.

So like add showInitiative to the indexing so you can just use the catalog for initiatives that are shown. Although, you probably lose sorting if you do it this way...

It really shouldn't be a problem at all though if they clear them out. It's just if they have 100 initiatives stacked up, there will be a performance hit--especially since this is on the main page.

Oops, also forgot.

If they ever decide to not display it in the portal root, it might not work. In the page template you have

here/initiatives/values

here is going to be relative to where the viewlet is being rendered so you'll want to use the portal root.

In order to do a catalog query that sorts based on the folder ordering do a 'sort_on':'getObjPositionInParent'

"'sort_on':'getObjPositionInParent' "

Nice catch Marshall! Never seen that before.

A couple more things yet.

You fixed the browser view class, but you didn't change the template at all to reflect it.

tal:repeat="initiative context/initiatives/values"

should be

tal:repeat="initiative view/initiatives"

what you got in the update call on the template. Getting the initiatives with the values like that would still go through every initiative and wake up every object.

Also, in your catalog search you should add getShowInitiative : True to it and save yourself a step in the template along with changing the indexer and metadata to getShowInitiative. Try to keep as much logic out of the template as possible.

One last thing, getRemoteUrl is already in the catalog so you don't need to add it to the product's catalog. And when you retrieve the value for it, you might want to use the "get" accessors for it since this uses the types field and get the value and accounts for missing values and such--might help with migration. The only things you really don't use the 'get' for is Title and Description for some reason. Not sure why. Maybe it's just an archetype convention.

Sorry for all the changes! This product is very visible and used a lot, so it is just important we do some of these things right.

Just picking at the low-hanging fruit: can't just show the first 5 because the point is to give them more control over which ones will show up, so that's number and order.

Re: waking up the objects, I agree we should go with catalog where possible. However is waking up the objects in this case that big a deal since we've got cacheing via squid? Squid of course won't help if there are a lot of logged in sessions, which I have been trying to discourage on the /home site.

We don't need to restrict the number they show as long as in the query you use the getShowInitiative = True or whatever we use for the indexer name. Then you should be fine.

It might not be a huge deal, but once they have 100 objects you're walking up for no reason, it could be noticeable. Even so, the fix is easy enough to implement and it'll reduce the possibility for headache later.

So what should be done is remove the number to show restriction and just assume they will use the showInitiative attribute to restrict the amount that show up. Then still use the catalog to query only those that are supposed to be shown and also order according to the order in the folder.

Remember that when you update the product on the site, you'll probably need to reindex the catalog since previously we weren't using the indexers and metadata.

Awesome. Good work.

Just a couple small things left.

You were using absolute_url on the regular initiative types which, since we're working with catalog brains not objects, should be changed to getURL. Also, there were some unnecessary comparisons in the page template--the query should do all you need. If it isn't, revise the query. Also, changed the name for the metadata in the catalog.xml.

I've made the changes. Non of this is tested, but it should work. Wow, first commit I've had to the uwosh repo in a while!