|
Author
|
Message
|
|
Paul Forsyth
|
Tuesday 30 November 2004 3:09:38 am
The toolbar proposal sounds identical to this ;) http://ez.no/community/contributions/applications/ez_cmf_developer eZ does need a tool like this. paul
|
|
Brendan Pike
|
Tuesday 30 November 2004 5:30:08 am
I thought the same thing, default & secure support for the eZ CMF Developer would be nice. By the way Paul, I think Firefox 1.0 doesn't accept the 0.4.2 extension (or is it just my browser - quite possible I corrupted a chrome)
www.dbinformatics.com.au
We are always interested in hearing from experienced eZ PHP programmers and eZ template designers interested in contract work.
|
|
Paul Forsyth
|
Tuesday 30 November 2004 5:41:55 am
Its a version number problem. Firefox has a min/max setting for the browser version the extension should support. I need to change a number from 0.10 to 1.0. Its a common issue with extensions before 1.0 :( I need to update the patches also for 3.4.4, which is the main reason the files havent been revised. Hopefully a new version will be out this December :) If you need a quick revised xpi drop me a mail. Anyway, we are off-topic now. Every developer addition is fantastic news. paul
|
|
Felix Laate
|
Tuesday 30 November 2004 6:01:35 am
Just an idea.. Would be great to have a syntax-check button in the admin-interface. Easy consitency/syntax-checking of the templates would certainly make my day better.. felix
Publlic Relations Manager
Greater Stavanger
www.greaterstavanger.com
|
|
Alex Jones
|
Tuesday 30 November 2004 6:53:51 am
It is exciting to hear that the next release will be developer-focused, thanks! Below is a feature suggestion, plus my thoughts on the previously posted suggestions.
<b>My Suggestions</b>
XHTML whitespace formatting - Basically, it would be really helpful if we had more control over the whitespace in the markup generated by eZ publish. At present, developers have to decide between nicely formatted template code, or nicely formatted XHTML output. While this is a small request, it would make debugging XHTML and CSS problems much simpler.
Previous discussions:
http://ez.no/community/bug_reports/template_logic_code_shouldn_t_produce_whitespace
http://ez.no/community/bug_reports/template_engine_adds_unwanted_whitespace
http://ez.no/community/forum/developer/lots_of_sections_and_html_whitespace Template Color Coding - This may prove too time consuming, but it would be really helpful if there was a view of the template code that had syntax coloring. Obviously, we can't color code the edit view, but providing a separate screen would be an immense help. While some programs will let you set up color coding for eZ publish templates (Eclipse), others will not (Dreamweaver requires angle brackets, not curly for tags). Plus, anyone who wants to edit templates through a browser would benefit greatly. The color coding wouldn't need to be too complicated, especially at first as it could grow over time. Ideally the color coding would be controlled by a tpl or ini and CSS, allowing the developer to easily change colors, text treatment and the like.
<b>Feedback on Other Suggestions</b>
Developer's Toolbar - This would be extremely helpful for developers Override Improvements - I really really really like the idea of the override overview page in the form of a tree. This would make it much easier to understand what is being overridden by which template(s). I think this should be combined with the Template Overview page suggestion, as it would make sense to see both the list of overrides and the templates that are included within other templates all within the same page. Debug Mode - I love the idea of the list of templates with links to view, edit and override them The ability to turn off specific types of debug information - A bit more control over debug output would be great. For example, at present, several of the sites I develop do not use any form of translation, and will not for the foreseeable future. While I don't want to remove the functionality from the CMS, it would be nice to eliminate the translation items from the debug menu as they do not benefit me. Thanks for posting the thread Frederik, I look forward to the final set of changes in 3.6!
Alex
[ bald_technologist on the IRC channel (irc.freenode.net): #eZpublish ]
<i>When in doubt, clear the cache.</i>
|
|
Lazaro Ferreira
|
Wednesday 01 December 2004 10:55:59 am
Hi, I don't sure this is developer usability, but it is a developer issue, documentation on best practices to extend ezpublish is something missing i.e : Custom Content Action, a concept or idea that sounds powerful at first, but we weren't able to use practically, it seems not fully implemented or at least documented to be useful
Also could be interesting the implementation of a wizard development framework
( something like you implemented for setup, but aimed to be generic ). This could make easier the implementation of user interfaces for multiple views/steps process
Lazaro
http://www.mzbusiness.com
|
|
Xavier Dutoit
|
Wednesday 01 December 2004 12:55:55 pm
I'm coding an event and quite frankly, that's a pain to debug. Any tool to smooth the process would be a great addition. You are using the templates for all the backoffice, but you don't use any workflow. It's like if the tool isn't enough good for what you Why don't you use the workflow to do things like handling the user sign in process, to bookmark nor the information collector ? Surely, all these tools could (should?) have been developped using the workflow system, isn't it ?
I'd suggest to fix the bugs and add a few basic features, like :
- You can't display a page on a workflow trigged by content (as opposed to the wrapping example for the order).
- You can't have a redirect
- You can't set a parameter in one event to get it from another one later on the workflow (I'm going to contribute something to address this specific issue next week),
http://www.sydesy.com
|
|
Hans Melis
|
Wednesday 01 December 2004 2:00:01 pm
Xavier, It is possible to set a parameter and use it in later events. The process parameters are what you need to use. Going back to the point now... The current workflow system is too limited. The whole trigger system should be replaced by something more flexible if you want to make heavy use of the workflow system. Making the multiplexer event the trigger system would be a good approximation of what it should be. As it is right now, the workflow system doesn't feel like it's part of the system. Debugging workflows is also a difficult thing. And once something goes wrong, it's hard to recover it. We try to avoid workflows as much as possible for all those reasons. And that's a shame, because a nice workflow system would be a very powerful tool.
Hans
http://blog.hansmelis.be
|
|
Björn Dieding@xrow.de
|
Wednesday 01 December 2004 4:52:09 pm
I have an idea about debugging/backtracing...
Like the PEAR does...
Maybe we can backtrace following items:
- template errors
e.g "Template error in line.tpl included by full.tpl included by pagelayout.tpl"
- eZDebug errors and warnings
"INI Group not found in eZINI line 123 in eZWebdavServer line 345 in webdav.php line 123"
- PHP errors and warnings
Looking for a new job? http://www.xrow.com/xrow-GmbH/Jobs
Looking for hosting? http://hostingezpublish.com
-----------------------------------------------------------------------------
GMT +01:00 Hannover, Germany
Web: http://www.xrow.com/
|
|
Frederik Holljen
|
Thursday 02 December 2004 12:33:32 am
Regarding the workflow system: You are completely right, the workflow system needs attention. In order to do it right however it needs more attention and time than we can fit into 3.6. Its time will come however.
|
|
Mark Marsiglio
|
Thursday 02 December 2004 6:42:16 pm
This is not necessarily a 3.6 feature idea, but certainly related to developer usability...there is a suggestion on the suggestion forum already as well. Basically, I would like to see a Contributions-type area in the community section of ez.no where developers could share templates, classes, functions, and code snippets. Also, some guidelines for how these items should be contributed in order to make them useful to others.
http://www.thinkcreative.com
Turning Ideas Into Strategic Solutions
|
|
Xavier Dutoit
|
Friday 03 December 2004 12:09:25 am
Most of us probably started by learning the template language through looking/tweeking the default templates. These should be crystal clear and commented. Please allow me to take an example to illustrate my rant :
{* Default object admin view template *}
{default with_children=true()
is_editable=true()
is_standalone=true()}
{let page_limit=15
list_count=and($with_children,fetch('content','list_count',hash
(parent_node_id, $node.node_id,depth_operator,eq)))}
{default content_object=$node.object
content_version=$node.contentobject_version_object
node_name=$node.name}
{section show=$is_standalone}
<form name="fullview" method="post" action={"content/action"|ezurl}>
{/section}
...
When you have difficulties to understand the language and what is into $node (BTW, put a comment to promote the |attribute(show) that's a life saver), you really don't need to ask yourself:
- Where do all these variables (with_children,is_editable,is_standalone) come from and what are there purpose? (still haven't got the is_standalone by the way)
- "listcount = and(..." ? Looks like one of these dreaded C line where you pack as many instruction into a line as you can. Really smart, but hard to decipher and at least unneedingly disturbing
- "content_object=$node.object" I own a pint to the one able to explain me the purpose of this line (not easier to read, quicker to type, easier to reuse ...)
- idem "node_name=$node.name" I only missed this comment: {* set the node name from the name of the node *} ;)
- "{section show=$is_standalone}<form name="fullview" method="post" action={"content/action"|ezurl}>{/section}". Ok you have a form that does the action "action", but only when alone... You don't understand what might be this action and then you wonder what this naughty node might do when left alone... ;) Have a look at the template code again, think of it as learing material, clean and comment, that's the best thing you can do for the new developers. About adding new instructions (if, for...). For my web sites, the section and fetch instructions are more than enough for 95% of the needs. The purpose of a template system is to separate the content and the logic, not to create another programmation language. Granted a "section show=" isn't that far away from a "if", but if you really want to add a showif instruction (for example), at least modify all the templates and replace the "section show" by the showif and obsolete the "section show". X+ P.S. Sorry for the rant.
http://www.sydesy.com
|
|
Frederik Holljen
|
Friday 03 December 2004 1:25:03 am
Xavier, We fully understand your rant, and we are addressing this problem in 3.6 by improving the documentation. You can expect that all views are documented with an explanation of the variables set, and what they contain. The idea is that you should not have to use the standard templates to learn the template language or how the views work. This should all be in the documentation. I agree that the standard templates may be cleaned up a little, but we are reluctant to add lots of comments since it may degrade performance. About the template language: The template language is separating content from presentation, not content from logic. Hence the functionality to create if/for and while constructs is needed, and already present. What we are talking about is to improve the syntax so it looks more similar to what people are familiar with (very close to creating aliases).
|
|
Ronny Vedå
|
Friday 03 December 2004 5:04:08 am
I think the if,for,while and break in the template language is a very good idea. I have wished this since 3.0. I would also like to suggest a new event system. A module could be able to register functions/methods that will be called on different events. The most important events would be: pre_edit - would be called before entering edit mode of an object. Editing may be aborted depending of the return value of the event. This could as an example be used to perform some extra access control on criterias that are beyond the current role system. pre_publish - would be called before the publishing of an object is performed. Publishing may be aborted(returned to edit mode with message) depending of return value of the event. This could be used to perform some extra validation. post_publish - would be called after an object is published. This could as an example be used to update a change log. I have used similar events in other systems and found them very useful.
|
|
Eirik Alfstad Johansen
|
Monday 06 December 2004 7:28:48 am
Hi guys, Pretty much all ideas so far seem great, so I won't comment on them, but rather suggest a few new functions of my own. It would be great if one could view (turn on and off perhaps) the template variables accessible in a template from the admin interface, or, more specifically, the template editing screen. If I had a nickle for every time I wrote attribute(show)... A versioning system for templates would also be nice. Several times I've found myself overwriting critical templates. Some times I've managed to to locate a backup, while other times I've had to spend several hours rewriting template code. Finaly, in addtion to Alex' suggestion on color coding, it would be great if one was able to tab (I wonder it that's a verb) lines for easier readability (this is, of course, not possible in a normal textarea). The lack of these two features (color coding and tabbing) causes me to always copy and paste the template code into in editor for editing in order to see what's what and maintain the tabbing. If someone were to create a sort of Developer OE with these features, I would certainly buy it!
Sincerely,
Eirik Alfstad Johansen
http://www.netmaking.no/
|
|
Ulrich L.
|
Tuesday 07 December 2004 7:06:53 am
Of course this is only a newbie's comment... but:
I wish the multilingual setup of the site would come more easily out of the box, not by manually setting up further siteaccesses and so on. The different languages should be accessable via the out-of-the-box design.
Why? Because this is a key feature of the software, and the steps for such multilingual install are very suitable for an automatic installation process, as I understand it.
I don't know how much work can be invested in an automated template creation process. For me the biggest disadvantage of ezpublish is the coding of the templates which is hard to learn, although very powerful. However, it behaves totally different from the setup of the content, which really can't be more easy! Other systems, while not being so flexible on the content side, offer more click-and-out-of-the-box design and are quite successfull this way... Ezpublish should keep an eye on this development.
|
|
Gabriel Ambuehl
|
Sunday 12 December 2004 6:14:26 am
I think the shop needs some work. First and foremost, I'd love to see better shipping workflows out of the box (say different rates for different countries).
Furthermore, I think it would be beneficial to turn orders into a normal content object so other tools working with content objects could be used for it. It would also help if the order class could have custom attributes (like order status) and as a normal content object, one could attach other data to it (like comments, sort of like basic CRM even). One could also use PDF export facilities to generate paper invoices, shipping documents and a lot of other
stuff that currently isn't so easily done. The way it should work (IMHO) is to have an Order class that uses objectrelationlist to refer to the items the user ordered.
Visit http://triligon.org
|
|
Tom C
|
Wednesday 29 December 2004 10:35:08 am
Within the documentation on ez.no, there is at least one request to develop a good Wiki and to use it for documentation. I want to add my vote for that. The current documentation is well-organized but limited by the capabilities of the system it's documented within. For instance, I prefer a more ordered list structure, like the documentation at mysql.org, which uses notation like this: 1.1, 1.1.2, etc., and which is printable in .pdf form and navigable/viewable in Html. Wikipedia's open source php-based MediaWiki has a lot of this capability (www.wikipedia.org). There is also another java-based wiki, which, from a users perspective, can give us many lessons to learn, and its popularity with high-powered users attests to its business utility: http://www.atlassian.com/software/confluence/default.jsp?clicked=footer This brings me to the second bird. I really need the ability to develop a website that has wiki workspaces which are assigned with granular privileges to various users and groups of users. Thanks for listening.
|
|
Tom C
|
Monday 03 January 2005 6:30:01 am
To go along with my wiki comments, I'll just note that Typo3 is experimenting with MediaWiki for their documentation: http://wiki.typo3.org/index.php/Main_Page The advantages of this are more apparent after getting beyond the main page. Perhaps there's no perfect solution.
|
|
Björn Dieding@xrow.de
|
Thursday 13 January 2005 3:53:23 am
As we all know the toolbar needs some rework. Somebody from eZ said your are looking into that for 3.5, but nothing did happend. So can we plan some amount of rework for 3.6?
Looking for a new job? http://www.xrow.com/xrow-GmbH/Jobs
Looking for hosting? http://hostingezpublish.com
-----------------------------------------------------------------------------
GMT +01:00 Hannover, Germany
Web: http://www.xrow.com/
|
