- everything is a folder (no folder content type)
idea is not new, its taken from limi's blog, but everything (except File, Image) content types should be folderish. - no Image content type
well Image is nothing more then extended File content type. what i saw in past was that users were confused that there are so many content types. by having only one content type it make plone even easier and close to file-like-system. - small/tiny/micro plonecore code base
when plannning next release please also consider developers happiness not only end-users. we are ppl too you know :P. what i mean is that 90% time i work with plone i really dont need all those features that are builtin. 90% time i need only 2 content types (Document, File) which i extend, superclass, ... this is again subject to argue about, whether plone is framework or software. why it couldnt be both? having light plone core which developers could use to build on it, and end users ready packages like plonefor.community (curent plone), plonefor.getpaid, plonefor.goverment, plonefor.education, ... - link content types, wtf?@#$%
maybe i should read some more end user doc but i just dont get what with link content types all about. just to store link to some page. i would expet form it to show content inside plone (like Windowz product), redirect to that link or even both options. but ofourse this is something that should not be in plonecore (menitoned above). - portlets+viewlets=widgets (or call it as you want)
again idea is nothing knew. all i would ask from plone4 is that it provides rock solid UI to manipulate with them. draging and droping please. - no XML please
i use genricsetup in day to day basis and writing all that xml is just not fun you know. we use perfect language - python - if you forgot. use it. it can do more then just magic. sonce XML is only computer friendly and if we really must use xml then an UI tool *must* be provided or if not next plone book should be "pistol for developers included - for self puprose only" - unified plone registry
this has nothing to do with windows registry so dont panic. its just some centralized way of storing site configuration that can be also (ab)used by add-on products. now we have a mess. every configuration is stored in its own way and place.
if i may dare this could also be next-generation of genericsetup (with no usage of XML ofcource). - no kss in plonecore, ship only with jquery
50% of time i disable kss since it slows down the site. yes kss is usefull but not in all scenarios. make developers choose whether they would like to write javascript or use kss. - developer reference documentation
this should be killer feature of plone4. currently there is no - or is really in bad shape - reference developer documentation. Christopher Warner few days ago wrote "If core code is undocumented it's broken". but who should be responsible for this? core developers. when there is new feature added/removed documentation should be alsoo updated. sphinx here offers a great way to document our code. it can be api, doctests, docstrings all in one. and can be done from the code ,so all those doctests, docstrings that are already there will be used.
- plone theming
deliverence promises a lot, but still plone itself must provide easier theming expirience. something as easy as old zope2 skins and scalable/reusable as zope3 resources. - wsgi out-of-the-box
this is a must, repoze middleware that is availiable now looks so usefull i'm just wainting for some project to try it out.
well this is it, for now ... i'm exited with plone4 release and now its time for me to go back to bed. i think by the end of this night i'll come up with few more.
3 comments:
everything is a folder (no folder content type):
everything should be related to something, so a folder is just an object which references other objects and list them. By default, a folder object, references the one added in his own space, or an object when added fire an event to tell "someone want me?".
You'll be happy to know that this list is pretty close to the list that the core developers have for Plone.
Of course, what features land in which release is — as always — dependent on whether there's development resources for it, and whether it is capable of being robust and scalable enough to be included before the PLIP deadline for a particular release.
It is important to understand that small or micro parts of a codebase are often the foundation that supports larger, complex features in applications, therefore, a good understanding of those parts can affect the overall quality and performance of the systems built on top of them. Thank you for the information.
Post a Comment