[Grok-dev] Grok-dev Digest, Vol 86, Issue 1

[Christopher Lozinski]

 1. Introduction
2. Grok Traversal Documentation
3. GrokCore Traverser Issues
4. My Application
5. Zopache Traversal
6. Anchors
7. Obviel Traversal
8. JQueryMobile Traversal
9. Conclusion: GrokCore.Traverser Proposal


1.INTRODUCTION

Thank you for your email, and for challenging my ideas. It really forces
me to think more clearly about what I am dong. It is a lonely business
being a grok developer nowadays.  Particularly TTW.
Lots to talk about.  You can skip tot he part that interests you using
the headings above. 

2. GROK TRAVERSAL DOCUMENTATION

So it turns out that grokcore.traverser is just a tiny part of the 
traversal code in grok. There is way way more in zope.publisher, grokcore.view.publisher and even zope.app.publisher.  It is documented here:
http://zopache.com/TraverserGrokcoreCodeDocumentation
http://zopache.com/TraverserZopePublisherSourceCodeDocumenation
http://zopache.com/TraverserZopeAppPublicationDocumentation

3. GROKCORE TRAVERSER ISSUES

On 8/19/14, 1:52 PM, Paul Sephton wrote:
> it makes no sense to me-

It is not you.  This stuff is just way too complicated.  We can make it
simpler.

In grokcore.traverer there are three classes.  The base class and two subclasses, one for traversing iContext, and the other for traversing IContainer.  I needed to change a method in the base class, and then adapt the two subclasses.  That means creating a base class adaptor, and two subclass adaptors.  Too complicated, I just turned grokcore.traverser into a develop egg, made the base class change and was done.  

Actually I think the original authors did the right thing.  The focused on performance.  But if the market claim of grok is 
that it is the best way to reuse components, then we need to make that component reuse easy. I propose that grokcore.traverser be a single class that tests if something is an IContext or IContainer. That makes is much easier to understand, and in my case much easier to adapt. Those who need better performance can then register more specific subclasses. While this is technically a small change.  It is conceptually a hugely different approach.  Simplify it for new users.  Adapt it for more complex requirements.  

I will come back to this proposal in section 9.Conclusion.  


4. MY APPLICATION

For those doing a simple application using parental acquisition, a typical structure might be as follows. 

/index
/Content
/ContactInfo/Content
/SubmitResume/Content
/PostJob/Content
/Resumes/Content
/Jobs/Content
/Home

so when one goes to the home page privacv.com we find the /index template, look up /content  and display it. 

When we go to privav.com/ContactInfo we look up the index page in the root folder, it asks for the Content in the  Contactnfo folder and displays it.  Simple.  This is the basic use pattern for parental acquisition. ContactInfo is the context for that view. Index is the template for that view.  

5.ZOPACHE TRAVERSAL

>From this you can  see why I need a custom traverser.  I look up the index template using parental acquisition.  The template has a view.  The view that grok calls now has a context, a request and a template.  

6. ANCHORS

First for those like me who did not know how the jquerymobile library handles anchors I quote: 

"One HTML document can contain more than one "page" element, and thus
more than one screenful of content. This way it is only necessary to
load one file which includes multiple pages of content. One page can
link to another page within the same file by referencing the page's id
attribute (e.g. href="#second")."

So that sounds like a great idea.  Kind of like the obviel idea, you get your anchorr text from somewhere.  Obviel from the server, JqueryMobile caches it in the html file.  

So both Obviel and JQuryMobile use anchors to display a particular "page".  Without arguing over whether that is a good idea or not, let us look at how to support it in Grok.  

Stating the obvious.  The goal is that the same thing should be displayed for a given url, whether the user clicks on it, or sends it to someone else. 

7. OBVIEL TRAVERSAL

Let us start with the simpler obviel case, and move to the more complex and interesting JQueryMobile case. 

There are two ways to think of the anchor
Either display the whole page, or just load the content. 

When someone navigates to 
privaCV.com/#ContactInfo
They are really trying to display /ContactInfo/Content
using the root (whole page) index method. 

But if they try to just click on the link, they want to load the content using the url

 privacv.com/#ContactInfo

In this case, Grok needs to travese to 
ContentInfo/Content

So Obviel requires two different traversals based on the referer URL. 
Fortunately this is all doable.  There is a method called defaultBrowser, really it should be defaultView that allows us to add some steps to the end of the traversal path. 


8. JQUERY MOBILE TRAVERSAL
Actually I now prefer the jquerymobile approach.  Given a URL, 
put the first content page first in the downloaded file, and while the user is reading it, download the other "pages" in  the background. 
That leads to much better user response time. 
That requires the obviel traverser, plus an extra step of downloading the extra data.  


9.CONCLUSION: GROKCORE.TRAVERSER PROPOSAL

I think that it important to take small steps and keep the big picture in mind.  The big picture is that Grok is brilliant software, I think that it is the future of software engineering, but it is sadly too complex.  With your permission, I can take a small step to simplify it. 

May I upgrade grokcore/traverser/components.py to only be a single class?  One that checks if the context is an IContainer, or an IContext.  That will be much easier for new developers to grok. It will be much easier for more experienced developers like me to adapt. I can move the two subclasses ContextTraverser and ContainerTraverser into separate files that those who care about performance can register, and that the rest of us can ignore.

And while I am at it I can move some of my source code documentation onto github.  

What do you think?