[Grok-dev] Re: Admin UI name change suggestion
Philipp von Weitershausen
philipp at weitershausen.de
Mon Oct 8 12:50:51 EDT 2007
Martijn Faassen wrote:
>>> It depends on what you mean by "getting started", right? It's less
>>> work to get a single application installed.
>> Please convince me that this *isn't* what 99% of the people starting
>> with Grok want and I'll be happy to reconsider my view :).
> Many beginners will probably expect the application to be installed.
> Others probably won't be surprised that it needs to be installed first.
> I agree though that grokproject could pre-install an application.
That seems to suggest you want to do it in buildout. I find that the
wrong place, still. I think it should be done during application startup.
>> From my experience from working with newbies, they don't detect the
>> "broken" state anyway. They wonder why their new utility isn't showing
>> up, or why they get a NotFound. I *always* had to explicitly tell them
>> that they had to reinstall applications. When I did so, it made sense
>> to them, but they too had to inform themselves about that fact.
> The UI should definitely help if this makes this visible. The current
> trunk shows broken applications in a different area explictily marked as
> broken objects. It didn't used to do this, but we ran into this in the
> grok tutorial I gave in august and Uli fixed this.
It might also be nice if we could mark outdated application objects
somehow. People will add a local_utility definition or a grok.Indexes
definition without realizing that they have to recreate the application.
>> I don't think anybody ever intuitively turned to the admin UI for
>> this. They were simply refreshing their browser pages, and found that
>> they stopped working.
> Hm, I wonder whether we can't make a clever default view for broken
> objects and/or error message that helps people find out. This is
> definitely something that trips up beginners.
IIRC, broken objects provide IBroken (see zope.app.broken), so that
should easily be possible.
>>> I don't understand how there are less concepts to grasp. People
>>> working with Grok will need to understand object publishing;
>> Yes. Eventually. I distinctly remember in the discussions around the
>> first prototypes of Grok that object publishing was not the first
>> thing people should have to learn
> Okay, then I misunderstood you. You're suggesting that the current admin
> UI forces people to learn object publishing right away?
> I don't see that?
The conversation went like this:
Noob: When I go to http://localhost:8080, I don't see my application.
Philipp: Right, you get the admin UI. You first need to instantiate your
Noob: Why do I have to instantiate the application? Doesn't Grok just
Philipp: Yes, it finds it. But you need to create a persistent instance
of it, so that your views are found. You see, Zope has this
model where it traverses objects to get your views, etc. etc.
... and I was right in that place where I was explaining object publishing.
>>> One wouldn't think they would be confused for long as soon as they go
>>> to localhost:8080, right?
>> I don't understand this question.
> Some people, as you say, are confused they need to install their
> application instead of it being for them. Confused, but unlikely to get
> *stuck* for long (which would be worse), as they won't be confused for
> very long as they'll likely see what they need to do as soon as they go
> to http://localhost:8080.
> If we pre-install the application the only thing they'd need to do is
> click on the actual application link. That reduces the amount of work
> they need tod o, and reduces the chance they'll get stuck to virtually
> They may still wonder how to actually deploy this as the root (should
> they so desire). That's a deployment use case. For that, we have various
> approaches, including WSGI/Paste, a UI option that will allow them to
> make an application into the default root, or a different way to start
> the server. We'll need to work out which one to pick (or perhaps
> multiple ones, one easy for beginners and one easier for sysadmins).
I think we have an agreement then.
http://worldcookery.com -- Professional Zope documentation and training
More information about the Grok-dev