|
Author
|
Message
|
|
André R.
|
Wednesday 14 November 2007 2: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..
eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom
|
|
Heath
|
Wednesday 14 November 2007 3:10:17 pm
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
Brookins Consulting | http://brookinsconsulting.com/
Certified | http://auth.ez.no/certification/verify/380350
Solutions | http://projects.ez.no/users/community/brookins_consulting
eZpedia community documentation project | http://ezpedia.org
|
|
Sylvain Bannier
|
Thursday 15 November 2007 12: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.
http://www.smile.fr
|
|
André R.
|
Thursday 15 November 2007 1:57:19 am
eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom
|
|
Knut Urdalen
|
Thursday 15 November 2007 6:12:46 am
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 ).
|
|
André R.
|
Thursday 15 November 2007 7:56:17 am
I agree, but aren't those screenshoots taken in drupal?
Bless you!</joke>
eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom
|
|
Knut Urdalen
|
Thursday 15 November 2007 1:11:44 pm
That's correct. Just used them to explain what I had in mind ;)
|
|
Heath
|
Thursday 15 November 2007 1:33:52 pm
@Knut I don't mind where they came from :) 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
Brookins Consulting | http://brookinsconsulting.com/
Certified | http://auth.ez.no/certification/verify/380350
Solutions | http://projects.ez.no/users/community/brookins_consulting
eZpedia community documentation project | http://ezpedia.org
|
|
André R.
|
Thursday 31 January 2008 1:28:32 pm
Some more discussion about class enhancements:
http://ez.no/developer/forum/suggestions/integrity_flag_element_in_the_class_definition
eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom
|
|
Mark Marsiglio
|
Thursday 31 January 2008 9:14:56 pm
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
http://www.thinkcreative.com
Turning Ideas Into Strategic Solutions
|
|
André R.
|
Friday 01 February 2008 12: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.
eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom
|
|
Piotrek Karaś
|
Wednesday 30 July 2008 9:24:52 pm
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... ;)
--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu
|
|
Kristof Coomans
|
Thursday 31 July 2008 12: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
independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org
|
|
Pascal von Büren
|
Thursday 31 July 2008 2: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/images/supplynet/companies/snapcat/eigene_objekte/benutzer/benutzer/pascal/demo_bilder/class_level/61733-1-ger-DE/class_level.png
Screenshot of the obejct edit interface (notice the yellow boxes):
http://snapcat.ch/var/storage/images/supplynet/companies/snapcat/eigene_objekte/benutzer/benutzer/pascal/demo_bilder/object_level/61749-1-ger-DE/object_level.png If this could help anybody, I'm free to share this as a contribution, just ask...
|
|
Piotrek Karaś
|
Thursday 31 July 2008 6:05:51 am
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... ;)
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 ;)
--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu
|
|
Andreas Kaiser
|
Wednesday 29 April 2009 6:22:23 am
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
eZ Partner in Madrid (Spain)
Web: http://www.atela.net/
|
|
jac lee
|
Sunday 07 November 2010 4:17:00 am
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.
|
|
Zeus Khan
|
Wednesday 29 December 2010 2:51:07 am
This attribute assigns a key to access an element. The access key is a single character from the document character set.
| aggregatable
|
Indicates that the class supports aggregation.
|
| aggregates
|
Indicates that a control aggregates the target class.
|
| appobject
|
Identifies the coclass as an application object, which is associated with a full .exe application, and indicates that the functions and properties of the coclass are globally available in this type library.
|
| case
|
Used with the switch_type attribute in a union.
|
| coclass
|
Creates an ActiveX control.
|
| com_interface_entry
|
Adds an interface entry to a COM map.
|
| control
|
Specifies that the user-defined type is a control.
|
| custom
|
Lets you define your own attribute.
|
| db_command
|
Creates an OLE DB command.
|
| db_param
|
Associates the specified member variable with an input or output parameter and delimits the variable.
|
| db_source
|
Creates a connection to a data source.
|
| db_table
|
Opens an OLE DB table.
|
| default
|
Indicates that the custom or dispinterface defined within a coclass represents the default programmability interface.
|
| defaultvtable
|
Defines an interface as the default vtable interface for a control.
|
| event_receiver
|
Creates an event receiver.
|
| event_source
|
Creates an event source.
|
| helpcontext
|
Specifies a context ID that lets the user view information about this element in the Help file.
|
| helpfile
|
Sets the name of the Help file for a type library.
|
| helpstringcontext
|
Specifies the ID of a help topic in an .hlp or .chm file.
|
| helpstring
|
Specifies a character string that is used to describe the element to which it applies.
|
| hidden
|
Indicates that the item exists but should not be displayed in a user-oriented browser.
|
| implements
|
Specifies dispatch interfaces that are forced to be members of the IDL coclass.
|
| implements_category
|
Specifies implemented component categories for the class.
|
| module
|
Defines the library block in the .idl file.
|
| noncreatable
|
Defines an object that cannot be instantiated by itself.
|
| perf_object
|
Adds performance monitor object support to a class.
|
| perfmon
|
Adds performance monitor support to a class.
|
| progid
|
Defines the ProgID for a control.
|
| registration_script
|
Executes the specified registration script.
|
| request_handler
|
Add this attribute to a class to expose it as an ATL Server request handler and enable it to handle HTTP requests.
|
| requestedit
|
Indicates that the property supports the OnRequestEdit notification.
|
| soap_handler
|
Add this attribute to a class to provide the methods necessary for handling SOAP method calls and exposing information about the services offered by this class through SDL.
|
| source
|
Specifies the control's source interfaces for connection points on a class. On a property or method, the source attribute indicates that the member returns an object or VARIANT that is a source of events.
|
| support_error_info
|
Supports error reporting for the target object.
|
| threading
|
Specifies the threading model for a control.
|
| uuid
|
Specifies the unique ID for a class or interface.
|
| version
|
Identifies a particular version among multiple versions of a class.
|
| vi_progid
|
Specifies a version-independent form of the ProgID
|
By: FHA Streamline Refinance
|
