|
Author
|
Message
|
|
Paul Etienney
|
Wednesday 09 February 2011 2:04:50 am
Hello, This is the forum part of a discussion started on Twitter. It started with this question from @andrerom : "Whats the top 3 "Don'ts" of #ezpublish ? Any concepts we should let go?" I feel it deserves more than 140 char. So here is the topic. -- What i think :
- ezxml has too many limitation. We should be able to freely build our pages. Limitation should be an option.
- template language : i do not understand why we use this layer. I guess pure php could do the same. No ?
- Information collection attributes : i dont know why but i feel it could be better.
-- Good websites creation --
My site : http://www.pauletienney.com
Twitter : http://www.twitter.com/p_etienney
|
|
Damien Pobel
|
Wednesday 09 February 2011 2:22:13 am
Hum troll detected with the point 2. As you're french, you can read these two blog posts and the associated comments :
- http://truffo.fr/2010/04/template-ez-publish-en-php/
- http://truffo.fr/2009/06/utilite-des-langages-de-templates-en-php/
For the point 1, perhaps you need an HTML datatype instead of eZXML. It's not that complicated to be done. In the past, there have been some contribution when eZOE was not free...
Damien
Planet eZ Publish.fr : http://www.planet-ezpublish.fr
Certification : http://auth.ez.no/certification/verify/372448
Publications about eZ Publish : http://pwet.fr/tags/keywords/weblog/ez_publish
|
|
Bertrand Dunogier
|
Wednesday 09 February 2011 2:27:54 am
- as Damien said, this is quite easy to workaround, but maybe HTML support should exist by default, with a list of allowed/disallowed tags. But overall, ezxml is considered one of ezpublish's strength rather than a limitation, as it makes real multi-channel publishing.
- Troll spotted ;-) But yes, there is a point here, and that point is that in some cases, you don't want the template engine, be it for performances reasons or to reduce the learning curve. On the other hand, our template language is really aging, and if it was more modern, we wouldn't have so many complains about it
- yeah, it might be a bit too limited, and not easy enough to use.
Bertrand Dunogier
eZ Systems Engineering, Lyon
http://twitter.com/bdunogier
http://gplus.to/BertrandDunogier
|
|
Paul Etienney
|
Wednesday 09 February 2011 2:45:18 am
About ezxml You are right, my problem is not really ezxml. It is the html limitation. As Damien said i could use an html datatype but with his solution i loose ezoe. About template language I guess it is a multi-thread troll war subject. I am just thinking that the template execution should be lighter. Maybe it just need an upgrade.
-- Good websites creation --
My site : http://www.pauletienney.com
Twitter : http://www.twitter.com/p_etienney
|
|
Thiago Campos Viana
|
Wednesday 09 February 2011 2:48:57 am
By @masev "an advanced role/policy settings (per attribute)". And create the option to group extensions by folder.
eZ Publish Certified Developer: http://auth.ez.no/certification/verify/376924
Twitter: http://twitter.com/tcv_br
|
|
Damien Pobel
|
Wednesday 09 February 2011 2:52:37 am
As said on twitter. Note : the order is not really relevant, I want all :-)
- true OOP (Interface / abstract class, ...) for Datatype, template Operators, the front controller, workflow... In fact for every part of the system. For instance, defining a true well documented interface for Datatype would make easier to write a new one. And while at it, totally refactor the way to create template operator, it's currently very painful due to the need to declare it in several places. Don't Repeat Yourself !
- an unified cache layer and even an unified file storage system. The idea is to make the system consistent and to be able to use different storage system for different kind of data (memcache, redis, database, filer, hard drive, ...)
- a reliable and efficient template engine : this one comes again and again over the years. The current one is buggy, unconsistent, slow and very frustrating to use.
A lots of work :-) and probably a lots of BC break... Cheers
Damien
Planet eZ Publish.fr : http://www.planet-ezpublish.fr
Certification : http://auth.ez.no/certification/verify/372448
Publications about eZ Publish : http://pwet.fr/tags/keywords/weblog/ez_publish
|
|
Ole Morten Halvorsen
|
Wednesday 09 February 2011 3:00:59 am
Hi,
- Module/views: most views end up being spagetti code. As an example, look at the ~1500 lines of mess that is kernel/content/action.php. There needs to be a better concept that allows cleaner code and better code reuse. The MVC framework would probably help a lot.
- Information collection: Need a more flexible approach to forms and one which is not tied directly to content classes. Sometimes you want to turn the result of a form into an object, sometimes you want to just send an email. Sometimes you need to do more complicated things like creating multiple objects, custom validation, multi-page forms, etc. Django has a really nice approach to forms: http://docs.djangoproject.com/en/1.2/topics/forms/
- Data types: Needlessly time consuming to write, even simple ones. Case in point, ezstring, ~400 lines for a datatype that does nothing but store a single text value + validation. Datatypes also hard codes things like post variable names which makes them very inflexible and they can't be easily tested or reused in other situations where the data might not come from POST.
- Bonus #1: Package system: Need a much, much, much better and unified way of getting content in and out of eZ Publish.
- Bonus #2: Getting rid of node, section and object ids. Working on bigger sites that typically has at least dev, testing and production environments using auto increment ids is a real pain as they are often not the same on all environments.
Ole M.
Senior Software Engineer - Vision with Technology
http://www.visionwt.com
http://www.omh.cc
http://www.twitter.com/omh
eZ Certified Developer
http://ez.no/certification/verify/358441
http://ez.no/certification/verify/272578
|
|
André R.
|
Wednesday 09 February 2011 3:02:26 am
"
By @masev "an advanced role/policy settings (per attribute)". And create the option to group extensions by folder.
"
policy: Discussed before, should be connected to attribute groups so it doesn't get to complex. extension groups: namespaces could be a soulution, by default use something like ext or ezpxt as namespace an allow additional namespaces with config.php settings. @damien / @Paul Template: and thats why ezctemplate was created, its way faster and more consistent. We are aiming at allowing php templates as well, but we don't believe it should be the default as it is not a good thing in large projects with many people with different skill levels involved.. The hurdle is of course to migrate to the new template language. Deprecating (trowing strict errors) on using array sytax for objects and opposite in current engine right now would help, but there are still some other issues like custom operators/functions and so on. eZXML: Yes it's to limiting, but it does provide extension points and features not available in html. So might be that a strict xhtml5 format with support for custom and embed tags is a way to go. But some wants to move toward docBook which might make it more difficult. Anyway, we want separation of design and content by default to be the case in the future as well, but maybe allow this to be configurable to some extent (pr class attribute preferably). @Ole Morten: object/node/section Id's: As of 4.4 you have working remote id's in nodes / objects and section identifier, so not so much of an issue anymore. But please expand if you think it still is.
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
|
|
Maxime Thomas
|
Wednesday 09 February 2011 3:07:04 am
My 2 pences :
- We should allow dependencies between content types. For example, if you have an article content type, you should be able to decline it under several kind of content : article about cars and article about boats. It will be more simple to manage, all the common attributes will be in the article class and all the others in their respective class. It surely can be done with what Thiago mentionned.
- We should allow dependencies between siteaccess. For example, you have your website in english and you create a new siteaccess in french, you have to copy all the siteaccess settings and just change the regional settings. It would be easier just to add the delta between the siteaccess french and english and mentionned that the reference siteaccess is the english one.
- The override system must be clearer. I cannot count the times I have lost my mind about knowing why settings were not applied... Maybe it can be flexible and you may choose the mecanism to apply regarding to your siteaccess. For example, you may want extension /override settings to be applied for one siteaccess but not for another one.
Good initiative elsewhere.
Maxime Thomas
[email protected] | www.wascou.org | http://twitter.com/wascou
Company Blog : http://www.wascou.org/eng/Company/Blog
Technical Blog : http://share.ez.no/blogs/maxime-thomas
|
|
André R.
|
Wednesday 09 February 2011 3:25:39 am
@Maxime Content class inheritance: Yes, the issue would be potential implementation complexity, but it is a good thing to have in this thread Siteaccess: Easy, add a site concept so siteaccess just contains things specific to the interface settings. Bonus: detach them from siteaccess so you can have generic frontend/backend/mobile siteaccesses and site specific setting in the site concept. overrride sytem: yes, good point. On this one we lack suggestions on what could be better though. There was one in the past about writing override rules in the top of your override templates, what you lose with that is that you need to add another level of parsing and caching and no single place to see all rules (beside potential gui).
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
|
|
Paul Etienney
|
Wednesday 09 February 2011 3:44:20 am
A big +1 to the form approach Ole described.
-- Good websites creation --
My site : http://www.pauletienney.com
Twitter : http://www.twitter.com/p_etienney
|
|
Gaetano Giunta
|
Wednesday 09 February 2011 3:57:28 am
Oh my, yet again one of those "waht's your most wanted feature?" topics. This is very nice for everybody to let off a bit of steam, but it has been done many times in the past (iirc I started a similar thread in the 4.4-roadmap timeframe), and it can degenerate quickly into an unusable mess. What we need 1st is a nice tracking system for new features, where users can vote single features up/down, add user stories, cost estimates and so on. In no particular order I'd want: more interfaces and better inheritance everywhere in php code; complete removal of the leftover include/require calls; a better crud system; moving shop and rss to extensions; a depth limitation in cache block expiry params; cleanup of existing datatypes; better and more pervasive info collectors; many more operations; permissions assigned to operations and not to views (the last two to move existing functionality to json/xml/rest apis); many more workflow events and triggers; simpler workflow event and datatype api; datatypes disconnected from http form fields; content/edit where the object_attribute_id is not needed anymore; ini system where the ordering is default,global,extension,siteaccess; merging the override folder in standard templates folder; remove override.ini altogether and only allow simple override rules (class, section, node_id); a much more complete and resilient packaging system; one-click install of extensions from external repositories with dependency checking; remove class id in favor of identifier; better translation interfaces for both ts files and content in the db (classes, states, etc); cleanup of all kernel views to remove business logic from templates and allow xml/json output; rename things here and there where they make little sense, and many, many more...
Principal Consultant International Business
Member of the Community Project Board
|
|
Matthieu Sévère
|
Wednesday 09 February 2011 4:05:23 am
"
What we need 1st is a nice tracking system for new features, where users can vote single features up/down, add user stories, cost estimates and so on.
"
+1, this topic can be endless dependig on everybody needs but most needed points need to pointed out ! I think there is lots of existing services that can handle that, for example : http://uservoice.com
--
eZ certified developer: http://ez.no/certification/verify/346216
|
|
Paul Etienney
|
Wednesday 09 February 2011 4:15:26 am
A huge +1 to Gaetano. This site needs a feature voting system. I am sure this "Here is what i dream about" topic is over discussed. How ever the initial question was more about big concepts and less about features ...
-- Good websites creation --
My site : http://www.pauletienney.com
Twitter : http://www.twitter.com/p_etienney
|
|
Bertrand Dunogier
|
Wednesday 09 February 2011 4:32:06 am
Well, maybe this did end up as a "wishlist" topic, but if you read the first post, the question was about "don'ts", not wishes ;-)
Bertrand Dunogier
eZ Systems Engineering, Lyon
http://twitter.com/bdunogier
http://gplus.to/BertrandDunogier
|
|
André R.
|
Wednesday 09 February 2011 4:33:02 am
Correct Paul, and the original twitter questions was original about what concepts to remove in favor of something else. A lot of suggestions so far are feature enhancements, not feature kill suggestions. aka: what Bertrand said :)
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
|
|
Lars Eirik R
|
Wednesday 09 February 2011 4:45:15 am
To stick to the topic.. remove the packaging and go for some type of xml scheme when it comes to deploy. Other large enterprise cms systems make it possible to synch between installations making sure that classes are kept intact. Today it is extremely tedious and not to say at least error prone to have to keep different environments identifical. Fixing deploy scenario and synch between different installations is something which is important to make sure that ezpublish can truely deserve the title enterprise system. One way to solve this would be to make sure that a framework runs a set of required implemented methods for each datatype. This would allow both custom as well as ez built datatypes to conform to a deploy scheme which would be extendible as well as reliable. PS: I am aware that some of you guys have heard this from me before...
|
|
Paul Borgermans
|
Wednesday 09 February 2011 5:11:35 am
To remove/replace top 3: 1) shop/e-commerce, should be in its own optional extension 2) packaging system (split into a data part and a general application package system) 3) index.php with a hierarchical MVC, possibly calling back to the old one (as in my original projectV idea) Paul
eZ Publish, eZ Find, Solr expert consulting and training
http://twitter.com/paulborgermans
|
|
Ole Morten Halvorsen
|
Wednesday 09 February 2011 5:31:12 am
"
@Ole Morten: object/node/section Id's: As of 4.4 you have working remote id's in nodes / objects and section identifier, so not so much of an issue anymore. But please expand if you think it still is.
"
Can you override templates on remote id? If you can then yes, that does help, although the creating two identical objects in two systems will result in different remote ids so you'd need to mess around in the db to set them to the same. Not optimal, but better than nothing. Ole M.
Senior Software Engineer - Vision with Technology
http://www.visionwt.com
http://www.omh.cc
http://www.twitter.com/omh
eZ Certified Developer
http://ez.no/certification/verify/358441
http://ez.no/certification/verify/272578
|
|
Ivo Lukac
|
Wednesday 09 February 2011 5:49:49 am
IMO there is no feature which should be removed, but lots of them could be better :) And those are many more then 3.
http://www.linkedin.com/in/ivolukac
http://www.netgen.hr/eng/blog
http://twitter.com/ilukac
|