[Grok-dev] Re: letting Grok take over the site

Uli Fouquet uli at gnufix.de
Wed Sep 19 17:08:06 EDT 2007


Hi there,

Am Mittwoch, den 19.09.2007, 14:35 +0200 schrieb Martijn Faassen:
> Shane Hathaway wrote:
> > Martijn Faassen wrote:
> >> Making the grok admin UI a grok application that users can select, as
> >> Shane suggests, sounds intriguing but I am not sure what it means. Could
> >> you elaborate, Shane?
> > 
> > Sure.
> 
> [snip a plan]
> 
> Sounds like a good plan. Now we only need to implement it. :)
> 
> Any volunteers to look into this? I would definitely need at least some 
> of Uli's involvement as the admin UI person. Uli, any comments/ideas on 
> how to go about making this plan a reality?

I am not sure, whether I understood Shane's plan correctly, so please
correct me, if I tell bullshit. Modifying the default traverser
behaviour is different from the UI being a 'standalone' application.

Anyway, the admin UI currently relies in several aspects on being a root
element. Changing this is possible but means some work (which I,
foreseeing this problem, already did in some other aspects, but many
still have to be fixed).

What first should be done in this respect, is IMVHO, to make the admin
UI a 'real' application, standing apart from Grok. This would also
weaken the dependency of the grok 'core' from the admin UI. They might
be delivered as different packages, which sounds cleaner to me than the
current approach. Being a real grok.Application object furthermore would
give some advantages to the admin UI, I would appreciate (possibility to
persistently store configuration values, for example). Beside this, some
update issues might occur, when the admin-UI implementation changes to
be persistent. 

However, I am currently pretty busy with improving the reference (which
from my point of view is more important) and trying to earn some money.
So I cannot start this project before the upcoming Neanderthal-sprint is
over. If someone else wants to start: please do!

Introducing a new namespace ++app++ from my point of view does not sound
too appropriate for the kind of problem we have (again, I might be wrong
here). If every application (including the admin UI) is installed under
a certain name, it is possible to access every application using this
name. The modified traverser's job would then be, to 'map' one of those
apps to the root. I may have missed the point here, but do we then still
need an extra namespace here, if the admin UI would be a seperate
application with an own name?

Until we have a real solution there is also the possibility Plone and
CPS users are used to: change the virtual host root.

Kind regards,

-- 
Uli

BTW: has someone (except Philipp) seen the i18n branch? I changed the
grok.i18n.registerTranslations-directive name to grok.localesdir.




More information about the Grok-dev mailing list