eZ Community » Forums » Setup & design » Content class (attribute) description?
expandshrink

Content class (attribute) description?

Content class (attribute) description?

Wednesday 14 November 2007 4:01:14 pm - 19 replies

One feature I miss in eZ Publish is "content class description" and "content class attribute description" in the admin-interface. This would be really helpful to create a more descriptive inline comments, an hence lighten the learning curve a bit. As a developer you could describe the classes and attributes as part of the setup so it's much clearer to the authors and editors what the various fields are actually used for.

Examples:
- "Short title - used in menus"
- "Valid from - the offer is only valid from this date"
- "Image - Max file size: 16 MB"
- "Alternative text - used for search engine optimization and for people with screen readers (set it to the same as the title)"
- "Banner URL - where to go when you click on the banner, please use an absolute URL"

You get the idea happy.gif Emoticon I see now that this could be done in the title of the field, but I think it's best to seperate the title and description so you can have more lines of description.

I'm wondering if this is a solution that could be custom made or has to be built in to the core.

Modified on Tuesday 11 January 2011 9:55:09 am by Nicolas Pastorino

Wednesday 14 November 2007 11:51:50 pm

I have suggested this internally before but forgotten about it.
It' shouldn't be to hard to implement, so I suggest you write a enhancement issue on it and get people to vote on it.

However my suggestion also included a way to categorize attributes. For instance you always have a lot of meta attributes that are not meant to be shown on the front end(show_children,allow_comments), and some 'class_meta' attributes shouldn't even be shown to editors while editing (number_of_children). Basically allowing us to use far more generic templates and control a lot more with classes and the role system..

Thursday 15 November 2007 12:10:17 am

This is a great suggestion in general and I really like André R.'s specific views on the topic.

<i>@Knut</i>

Please file an enhancement request and publish the link to the issue you file here back in this forum thread for others to promote, subscribe and vote for ...

Cheers,
Heath

Thursday 15 November 2007 9:21:07 am

Hi,

I'm insterested in this feature too.
It would be great to display forms labels, tooltips and to export documentation about classes.

I've submited an ehancement request #011932
http://issues.ez.no/IssueView.php?Id=11932&activeItem=1

Hope you don't mind.

Thursday 15 November 2007 10:57:19 am

Thursday 15 November 2007 3:12:46 pm

Usability wise I suggest that the attribute description should be displayed inline after the actual input fields (see http://www.urdalen.com/ez/attribute_description.png ). It's secondary information for those who care, but it should not be hidden and require additional user interaction to see it.

Attribute groups would be a nice addition for complex classes. When composing a new content class with attribute groups you would have some attribute groups that include required fields and should be expanded by default and some groups that contain additional information and could be collapsed by default so the user don't get scared about all the input he need to fill out (see
http://www.urdalen.com/ez/attribute_groups.png ).

Modified on Thursday 15 November 2007 3:13:22 pm by Knut Urdalen

Thursday 15 November 2007 4:56:17 pm

I agree, but aren't those screenshoots taken in drupal?
Bless you!</joke>

Thursday 15 November 2007 10:11:44 pm

That's correct. Just used them to explain what I had in mind blunk.gif Emoticon

Thursday 15 November 2007 10:33:52 pm

@Knut

I don't mind where they came from happy.gif Emoticon

I studied these before some time ago yet hesitated stepping up to make the very suggestion you have.

I think using them as examples of just one possible improved default design / solution is valid.

In the end these are valuable features which I think are worth incorporating into future versions of eZ Publish and so do a number of others silently agreeing with you.

This exact example might not be needed by everyone but in general we would prefer to have these features (which we could omit or disable ourselves as needed later).

Cheers,
Heath

Thursday 31 January 2008 10:28:32 pm

Some more discussion about class enhancements:
http://ez.no/developer/forum/sugg...flag_element_in_the_class_definition

Modified on Thursday 31 January 2008 10:38:18 pm by André R

Friday 01 February 2008 6:14:56 am

How about the Attribute Help Text extension? I use this all the time and it does pretty much exactly what is described above. http://ez.no/developer/contribs/hacks/attribute_help_text

Friday 01 February 2008 9:25:56 am

Looks like a fine extensions, but I think this suggestion aims at using the db instead of ini files for the description text. It's also a requirement that the helper text is translatable. And while on it the default values on ezstring and some other datatypes should also be translatable.

Thursday 31 July 2008 6:24:52 am

Sylvain wrote:

I've submited an ehancement request #011932
http://issues.ez.no/IssueView.php?Id=11932&activeItem=1

This issue seems to be closed... why?

I'd also would like to support this class/attribute extra info idea. While I like other suggestions as well, this one seems very easy to implement, carries little risks and in my opinion brings the biggest value around.

Also, when it comes to extra information, here's my thoughts on the subject:

There should actually be two extra text fields per class and per attribute. One user-dedicated translatable extra info/hint/help-like attribute that was discussed that could be used for inline or popup suggesions, help, hints etc. Second, translatable or not - not sure, admin/developer-dedicated for stored implementation documentation, that would never be visible for end-users. While managing attributes is meant to be easy in eZ, it is actually not trivial if you change some settings in class definition and may lead as far as loosing data or turning the site upside down. It would be great to make an implementation doc in the classes, first for having them there to read before any change, second for being able to export/print a documentation when the implementation is ready.

What do you think about it?

It would great if those features (especially those easy ones) could make it into 4.1... blunk.gif Emoticon

Thursday 31 July 2008 9:36:44 am

Hi Piotr

This specific issue you refer to was closed as a duplicate, because it was requested before. The original enhancement request is linked to, check under "Links".

Cheers

Thursday 31 July 2008 11:09:57 am

Hi everybody,

we have solved this problem (at least for our needs) by creating a new datatype, that doesn't store anything on object attribute level, only on class attribute level.

So you can easily add a new attibute above (or below) an other attribute that needs some explanation. The rest is up to the template you create for the edit interface.

Screenshot of the class edit interface (notice the <b>Infoelement</b> Attibute:
http://snapcat.ch/var/storage/ima...level/61733-1-ger-DE/class_level.png

Screenshot of the obejct edit interface (notice the yellow boxes):
http://snapcat.ch/var/storage/ima...evel/61749-1-ger-DE/object_level.png

If this could help anybody, I'm free to share this as a contribution, just ask...

Thursday 31 July 2008 3:05:51 pm

we have solved this problem (at least for our needs) by creating a new datatype, that doesn't store anything on object attribute level, only on class attribute level.

Yup, that's definitely doable, it's just slightly against good practices in my opinion - provided you want all of your attributes documented or hint-wise, you double your DB's attribute table row count... That considerably nice solution for occasional use, I agree, but rather not as a standard documentation or hint tool.

Actually, you could move your solution out of the class definition, and simply bind a manageable dictionary to attribute IDs + prepare an operator or fetch that would check if there's anything available. It would be less intuitive, but less overheadish. Still, nowhere near solutions suggested above... blunk.gif Emoticon

Cheers,
Piotrek

Edit: It's all about not having to come up with solutions that are expected to be out of the box by many blunk.gif Emoticon

Modified on Thursday 31 July 2008 3:06:47 pm by Piotr Karaś

Wednesday 29 April 2009 3:22:23 pm

Sorry for opening this old thread... but perhaps this new project can be used in case of needing contextual help / attribute description:

http://projects.ez.no/cjw_contexthelp

Sunday 07 November 2010 1:17:00 pm

One user-dedicated translatable extra info/hint/help-like attribute that was discussed that could be used for inline or popup suggesions, help, hints etc. Second, translatable or not - not sure, admin/developer-dedicated for stored implementation documentation, that would never be visible for end-users, wholesale nike shoes.

Wednesday 29 December 2010 11:51:07 am

The reply has been removed because of violation of forum rules.

Thursday 20 October 2011 2:08:39 pm

The reply has been removed because of violation of forum rules.

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from