ListIt Extended - Categories

[Stikki]

Hey,

Many of you have been opening Bug reports and been wondering about following subject, so i tough that i'll open sticky post for 30 days, so not so needed bug reports can be avoided.

Below you can find mostly asked questions regarding subject and few other questions.

Categories names not present, what to do:

Previously when items couldn't have more than one category, category info was
included in item object.

Now, when you can have item with multiple categories, categories are included to
item as ID array.

in 1.4-beta1 i didn't add any template methods, so you could actually load
category by ID inside template and use category objects to pull out information.
This is fixed in GIT, added smarty tag called: {ListIt2Loader}. For now only way
for you is to make temporal UDT to load this information in template context.

Why item ain't holding category objects?

Answer is simple: you don't always need category info, and it's useless to load
category objects when you don't need em. This saves a lot of memory / processing
time.

Why there is no internal method in item object to pull out data from it's
categories?

Because i attempt to keep category and item objects footprints as small as
possible, therefore i created smarty tag to do this instead.

What are my options now?

You can either go back to 1.3.2, as it's officially working version, or you can
create UDT that pulls information you need.

When is 1.4 expected to be released?

I try to push it out before summer, that's all i can say.

-Stikki-

[velden]

Thanks for the clarification.

A follow up question: if one calls ListIt2 with category argument. Is it then possible to 'know' the value of that argument inside template?

As items can hold multiple categories, using that information is not reliable.

Use case:
ListIt2 instance holds multiple items (links is this case). Every links is attached to a category.
ListIt2 is called in summary 'view' with one category as argument. Summary template should print heading with category name, and below that the links of that category.

[Stikki]

when items are in hierarchy,

Summary template assigns current category into {$category} variable.

I might change or prefix this at some point to avoid smarty namespace collapse.

If hierarchy links aint being used, this variable is not present, only appears when using hierarchy links.

If this is what you were asking.

-Stikki-

[velden]

Example:

Summary template:

Code: Select all

<div class="links-wrapper">

<h4 class="orange">{here should print the category name}</h4>

<ul class="links">
{foreach from=$items item=item}
<li><a href="{$item->fielddefs.link.value}" target="_blank">{$item->fielddefs.link.value|regex_replace:"/https?:\/\//":""}{if $item->fielddefs.omschrijving.value != ''}&nbsp;-&nbsp;{$item->fielddefs.omschrijving.value}{/if}</a></li>
{/foreach}
</ul>	
</div>	

In content area of some page:

Code: Select all

{ListIt2Links category='referenties'}
{ListIt2Links category='vleessector'}

Now I'm using:

Code: Select all

<h4 class="orange">REFERENTIES</h4>
{ListIt2Links category='referenties'}
<h4 class="orange">VLEESSECTOR</h4>
{ListIt2Links category='vleessector'}

which works fine, but is not that fool proof as it could be. And of course it's more flexible if one changes a category name it automatically changes from within template.

I do realize that more than one category could be called, so an array of category names should then be available from within summary template.

[Stikki]

{ListIt2Instance action='category' show_items=1}

To list categories and items under those categories.

-Stikki-

[GroeneKaktus]

Thanks Stikki for this nice new functions to ListIt !

Do you by any chance know where the fieldset_start and fieldset_end types did go ??

Regard, Jeroen

[Stikki]

Yes,

To the dumbster.

Do it in templates.

[GroeneKaktus]

Yes,

To the dumbster.

Do it in templates.

Hehe, alrighty, clear! but, Bummer !

The main reason I use them is to nicely seperate different area's in the admin, that way, if there's many field definitons, the fields can be presented in a categorized way to the editor of the items, instead of having all the fields all on top of each other on the page.

So templating can be done at the frontend, but in the admin it's now not possible anymore to "seperate" the fields.

Perhaps food for thought

Regards,

Jeroen

[Stikki]

Well each element that is field definition, brings more load on item objects, i don't want this.

This is not form builder, it's database tool.

We attend to make things highly user friendly at the backend, while keeping it very strict what you can do. This is to maintain performance.

If you wanna modify admin side templates, you have to use module_custom directory to overwrite default ones. Fields are simply looped in and behave similar way that they do at frontend, so i don't see much problem customizing it for client.

Tabs are coming, but i am not considering to add fielddefs back, as that's not data element of any kind.

-Stikki-