[Grok-dev] mass ping - grokui.admin

[Souheil CHELFOUH]

yes :)
I'll try to clean the current grokui refactoring to get it ready for
you people to try.
As for the dependencies, yes, I try to keep it minimal
We could also, out of the box with grok, provide a grokui.jsplugin (or
named otherwise), that could have nice eye-candy rendering, so we
don't look too austere.
Next week should see the rise of the new admin :)

2010/1/23 Martijn Faassen <faassen at startifact.com>:
> Hey,
>
> Souheil CHELFOUH wrote:
> [snip]
>> During the Cologne sprint, we decided to temporarly part from the
>> introspector, to focus on the simple CRUD application admin.
>> Where do we stand now, about this ?
>
> I think it's good to continue in this direction.
>
>> I think i'm part of the advanced users of Grok and I never had a
>> single need of the intropsector.
>> it looks cool and it's pretty, but is it useful ? Do we want it out of the box ?
>
>> if we do, what should we do about it ? What should I base the
>> forthcoming introspector on ?
>
> I think we should temporary forget about the introspector in Grok 1.1.
> We can bring it back sometime.
>
>> if we don't, I need to clean a bit the code base, and we have a nice
>> grokui base (including grokui.base and grokui.admin).
>
> That sounds good.
>
>> The current admin (0.3.2) is simply not good enough, as it pulls out
>> all the packages we wanted to get rid of with the zope.app move.
>> I think we need to focus a bit on that package, as it's the very first
>> glimpse people get of Grok, when they try it out.
>
> Agreed.
>
>> I'd like us, community people, to think about a schedule and a move
>> for this package.
>> I don't mind coding it, but, honestly, right now, I feel a bit lost as
>> I don't really have a goal.
>
> I think we should have a core grokui.admin package that just allows
> someone to install applications, and do some basic things like a restart
> perhaps.
>
> As an aside (for post Grok 1.1): we could also consider another "mode"
> that seems to be popular with other application frameworks, where we
> simply let the instance and the app be the same. When you start the
> instance, you got yourself an app. I was resistant against this in the
> past, and I still it's valuable to be able to install multiple apps into
> a single instance, but we should at least consider how this might work
> (can the app be persistent, what happens if you change the persistent
> app, etc).
>
>> Thank you for reading my whining
>> I hope I'll get LOADS of feedback on that
>> At least one, to give me a hint on what's expected :)
>
> I expect:
>
> * a grokui.base package which gives the grokui user interface in some
> pluggable manner.
>
> * a grokui.admin (perhaps?) that allows the user to install and
> uninstall apps and a few other things. Should have relatively small
> dependencies.
>
> * in the future: a reborn grokui.introspector. We'll see who wants to
> work on this.
>
> * also in the future: a grokui.config. This would provide a user
> interface to manage configuration that's persistent (per application).
> This includes things like the catalog, user management, but also
> app-specific settings. I think many applications would be fine if we had
> a default UI for such features.
>
> UI-wise I'm also slowly exploring another direction entirely as well, a
> javascript-based client that allows CRUD of data (ZODB or relational),
> building on Grok's model-driven nature and restful webservice platform.
> I think that can be a separate development independent from grokui, however.
>
> Does this help with direction?
>
> Regards,
>
> Martijn
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> https://mail.zope.org/mailman/listinfo/grok-dev
>