[Grok-dev] Re: Admin UI name change suggestion

[Philipp von Weitershausen]

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?

Yeah.

> 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
          application.

Noob:    Why do I have to instantiate the application? Doesn't Grok just
          find it?

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.


> [snip]
>>> 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 
> nothing.

Agreed.

> 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).

Yup.

I think we have an agreement then.

-- 
http://worldcookery.com -- Professional Zope documentation and training