Friday, November 21, 2008

plone-coredev with git (recursive svn:external solved)

months ago i migrated my projects to git. i wont go into debate why git, maybe this is for another post, but one of reasons was that it also seemlesly integrates with subversion. so you can use git on svn repos too.

if you are an old svn user and want to give git a try here is a nice tutorial with comparison to svn commands ( there are also other good tutorials on the web, uncle google is the guy to ask.

there were some cool changes in plone-coredev/trunk lately so this is a reason more to give it a try. but ofcourse i'll use git. there are many svn:externals which git-svn does not support but there is a workaround ofcourse. so lets start...

rok@bestia ~/Projects $ git svn clone --trunk=trunk --branches=branches --tags=tags --revision=21212:HEAD
rok@bestia ~/Projects $ cd plone-coredev

this only pulls buidlout from svn, svn:externals are not pulled out. now we use git-externals script which will pull svn:externals.

rok@bestia ~/Projects/plone-coredev $ ./path/to/git-externals
... fetch a coffie/tea/beer this will take time ...
rok@bestia ~/Projects/plone-coredev $ virtualenv-2.4 --no-site-packages ./
rok@bestia ~/Projects/plone-coredev $ source bin/activate
(plone-coredev)rok@bestia ~/Projects/plone-coredev $ python2.4
(plone-coredev)rok@bestia ~/Projects/plone-coredev $ buildout -v
(plone-coredev)rok@bestia ~/Projects/plone-coredev $ instance

and you have plone-coredev/trunk running... from first tast ... its fats :)

so what that does that git-externals script do?
its a script i wrote today, probably is buggy as hell but it works for now. it clones svn:externals in place they should be. in every package that has svn:exernals, .svn-externals file is created. reason i created it is because i didnt found any that can handle svn:externals recursivly. so here it is, ...

if you have any ideas, wishes, suggestions just write on rok-dot-garbas-at-gmail-dot-com.

Wednesday, November 19, 2008

z3c.form in viewlets

i blame hannosch for not to be able to sleep tonight :P (previous post)

my obstacle today/tonight was z3c.form+viewlet coctail. after 2h of testing and optimizing i got quite nice peace of code:


now instead of wrapping with FormWrapper we wrap with our new ViewletFormWrapper, like:
OurViewletView = wrap_form(OurCustomZ3CForm, __wrapper_class=ViewletFormWrapper)

all that is left to do is register OurViewletView with browser:viewlet directive and form is ready.

i found this wrapper really usefull and i hope it can get into plone.z3cform. or is there any other way of doing this?

my plone wish list

i just read hannosh's "News from trunk ..." before going to bed and as a result of this i woke up in the middle of the night (its 2:30am here) to write this blog post. i will just write things that i wish would be in plone4. some of this are unpolished ideas, some of this are just pain that i'm expiriencing.
  • 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 (curent plone), plonefor.getpaid, plonefor.goverment,, ...

  • 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.
--- after a while i found some more ---
  • 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.

Wednesday, November 12, 2008

one week of riding sphinx

i made 3 releases today to pypi:
  • SphinxBuilder
    buildout recipe for sphinx. that way writing/deploying sphinx docs becomes easier. initialy code was written by tarek i brought it from 0.1.2 to 0.2

  • AutoATSchema
    extension for sphinx which documents archetypes schema automaticaly
    .. collective.sphinx.autoatschema:: my.packages.content.mycontent.MySchema

  • IncludeDoc
    another extension for sphinx which includes doctest from also other packages.
    example usage:
    .. includedoc:: my.package:/relative-to-package/path/README.txt
inititaly i start looking into sphinx to see if also plone can also benifit from this usefull tool. i'm still doing research and will shortly publish my results and my ideas how to use sphinx in plone process.

i must mention that work on SphinxBuilder and AutoATSchema was sponsored by Headnet. thank you Headnet.

where to go from here?
you can see work in progress for possible replacement of well its only research so currently only tree packages are there: plone.contentrules, Products.Archetypes, Products.ATContentTypes. there are a lot of stuff missing consider it as staring point.

why i think sphinx is the right tool for
  • definitly *not* because sphinx is new hot stuff, but because of its features and because it makes can integrates well in plone proccess
  • very few ppl uses because of its current state. plone was by some extend ment to be framework and frameworks needs good, clear api so new developers can "plug-n-play"
  • we all know that api is not the strongest point of plone. well i could criticise it, but that wont change anything. with sphinx we can hide bad api parts or emphasise good / useful ones.
  • best / up-to-date documentation can only be written by core developers at the time of development (and maybe reviewed by doc team). well maybe not only but is sure the easiest way for all. we all are aware of TDD, there is several very well writen doc(test)s, but hidden from eayes of public.
  • because i think this can be the stongest feature for plone4. yes, having up-to-date documentation can do magic or at least attract more developers.
wanna help?
join us at where we brainstorm about possible options.