Re: Plone development list and bugs

[Johannes Raggam <raggam-nl adm at>]

On Wed, 2010-12-08 at 23:20 +0100, Gil Forcada wrote:
> > seems like, that you didn't move the
> > https://svn.plone.org/svn/collective/gnomeweb-plone/wgo.linguasync/
> > repository, which implemented all the translation sync stuff to reflect
> > the gnome language translation workflow.
> 
> I just imported that one [1] and wgo.mainpage [2].
> 
> For the first, at least looking at the source code, doesn't look like
> it's a regular submodule you put under src/ right? It's just an external
> module not tied-up with the other modules?
no, wgo.linugasync has a setup.py which makes it a normal python package
and it uses configure.zcml, which let it play together with zope/plone.
so it's safe to put it into buildout's src directory.


> For the later, do you remember if it's still valid or wgo.theme [3]
> super-seeded it?
yes, forget wgo.mainpage. wgo.installsite configures Products.Collage
which replaces functionality defined in wgo.mainpage.

> 
> > i *think* that collective.plone.gsxml, which was used for importing
> > content, isn't used anymore. i'm not very sure about that, but i guess
> > so. but if it's working, it might be ok to leave it where it is. i have
> > developed the create_item functions as an alternative to define a
> > content structure as dictionary which can then be used to create content
> > in a plone site (see: wgo.installsite.setuphandlers-basic_content). this
> > tool lead into the development of
> > https://github.com/collective/collective.setuphandlertools/
> > which may be used for importing content and other stuff, if needed.
> 
> Nice to know about it.


btw. wgo.policy is just configuring the diff_tool. i'm not sure if we
need it (if, i guess for translating). anyways, we can drop it and put
the diff_tool configuration - if really needed - into wgo.installsite.
then we should also drop collective.plone.gsxml since it's a legacy
package. we should clean up everything... there are a lot of
questionmarks arising in my head and i'm asking myself what we did there
back then... e.g. collective.indexing... do we need that? guess not.  

btw.2: are you planning to use plone4 instead of plone3? if yes, i'll
support that decision. plone4 is just better.

JUST IGNORE THE FOLLOWING IF EVERYTHING IS FINE:
btw.3 instead of using submodules, wouldn't it better to use the
buildout extension mr.developer? i'm not very familiar with git
submodules, but i guess it won't automatically configure the python path
to each package in buildout's src dir? anyways, then you can set it via
buildout.cfg manually and get the same effect. but
for doc see here: http://pypi.python.org/pypi/mr.developer
for an example here:
https://github.com/thet/thet.grak.buildout/blob/master/sources.cfg
and
https://github.com/thet/thet.grak.buildout/blob/master/buildout.cfg



> 
> Since you have some prior knowledge about the past efforts on bringing
> Plone to GNOME would you mind coming to the upcoming IRC meeting about
> it?
> 
> It will be on Sunday December 19th at 20:00 GMT on
> #webhackers irc gnome org

yes, i've marked my calendar and try to be there.

cheers,
,,,hannes







> 
> Cheers,
> 
> [1] http://gitorious.org/gnomeweb/linguasync
> [2] http://gitorious.org/gnomeweb/mainpage
> [3] http://gitorious.org/gnomeweb/theme
> 
> > 

> 

-- 
johannes raggam / thet
python plone zope development
http://johannes.raggam.co.at/
mailto:johannes raggam co at
http://bluedynamics.com/