Some code thoughts - mod_flexicontent

I'm looking at the modules/mod_flexicontent/helper.php
I will post my proposed changes in a while, but they will be minor and concern some features I need.

I have 2 suggestions:
1. There is a number of lines of the same code for featured and standart items. The difference is only in the _feat suffix. Altering such a code demands twice changins.
My suggestions is to move it to a function to call it with the suffix parameter - _feat or no. We can reduce the number of the code lines sugnificantly.

I can rewrite this, but I need to be sure it will be applied in the next buiilds.

2. When I want to show items's fields in the module
it requests firstly ALL the availabe fields here:

and later removes unneded. Is thir correct? Isn't it an overload? I'm not familiar with the code yet, but I think it would be better to create a function to fetch a field or a set of fields, but not all the universe of the fields. Function FlexicontentFields::getFields is a heavy one to be used in the module, as for me.
Maybe it's worth to create another function for frontend, much lighter.

But in this point I'm not sure. Maybe the data is loaded anyway on some other reason. This can tell someone more familiar with the code.

Still I can help with the code ecnhacement, but I must be sure I understand the logic in a right way not to make mistakes.

ok i send it georgios
thanks for you return !!
regards

Actually this function is optimized.

-- It retrieves multiple field value for multiple items at once,
-- creates parameters once per field type

the other field you see there are core fields, maybe the "text" field could be an issue if you do not use it since it involves plugin triggering

the main bottleneck in performance is calling joomla content plugins ...

i plan on profiling the code to identify sections that may have room for improvement.

v1.5.6/v2.0 have a lot of performance improvements compared to v1.5.4/v1.5.5

Regards

Ok, the fields are loaded without overusing resources. I get a field from ANOTHER type when loading it via moduyle (like explained here www.flexicontent.org/documentati ... field.html . I can't image how, but ok (-:

And what about the code duplication?

---

Here are my current badly needed changes.

I want to output item's category name in the module. The context is concerned to this tutorial - www.flexicontent.org/documentati ... field.html

So I want to output some related fields and the category of the related type (the fields belong to the type).

Currently mod_flexicontent doesn't pass the category info to the module template. So I've added an option in the module to fetch it.

So the language string for
language/en-GB/en-GB.mod_flexicontent.ini
are (cool, multyline is supported)
and the here are the 2 modified files (my changes are marked with ##mygruz, so you can easily find them)
modules/mod_flexicontent/helper.php
paste.opensuse.org/23817185

and modules/mod_flexicontent/mod_flexicontent.xml

paste.opensuse.org/71483853

about duplicating code, yes we could unify it, about passing category info of the items to the template,

we could add item category info without this without having a new parameter (i 've added $item->itemcats an array of item's category ids) , will be on next public revision, (but most important i have some issues to fix)

Also because category info is commonly used we have a cached global array for category information (you do not need to queries categories table), use:

global $globalcats;

print it to see its structure

Regards

Damn... I want to cry... I spent 2 days in a rush to make it work as expected, altered dozens of files, outputted megatones of dump info.... And now you tell me use this 2 line:
I really don't want to live futher... I mean thanks. I'm a "absolutelly useless monkey", like one my pal says.

---

The code duplication. Please looks at the helper.php

There is a line
P.S.
Do you think such a simple name $globalcats in global context is safe? I think that FC shoud use a global namespace with a more unique name.
Besides Joomla removed global $mainfraime; on some reason. Maybe FC should move in the similar way. Maybe I'm saying something silly, then sorry.