web dev/mysql guys/gals

[bruce]

Hey..

Anyone here have skills with the logic for a test app to allow the user to iterate through parent/child levels, and then be able to reverse the process through a beadcrumb process...

I can craft a "soln".. but wonder if anyone here has implemented something like this..

TBL1->TBL2->TBL4
 and on the page for tbl4 data.. the user would be able to go back to

 tbl2 and see th tbl2 page data...

TBL1->TBL2->TBL3->TBL4

 and on the page for tbl4 data.. the user would be able to

  go back to tbl3/tbl2 etc.. and see the results..

In this case, which represents what I'm going to deal with,

 the data from TBL2 could have TBL3 or TBL4 as a child tbl..

think of a dept that may have as a child, the page with the

 class/section data..  or.. the dept might point to a list of

 classes, with each class then pointing to the section data..

thanks

[ginnyjollykidd .]

This reminds me of when I was learning C. There was a recursion exercise we were supposed to do for the Towers of Hanoi, which leggy) left me severely scratching my head. When we were shown the program, I think there were three lines of code in it —no more than 5—and I figuratively tore my hair out at the one line recursion code.
I'd have to go back and check my C book for the logic. It's been  almost 20 years.
(it still surprises me that 20 years is no longer the majority of my years!)

--
You received this message because you are subscribed to the Google Groups "LVL1 - Louisville's Hackerspace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lvl1+uns...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brian Wagner]

You are right, this is a classic recursive tree algorithm.  Those make my head spin too!  Here is wikipedia to get you started https://en.wikipedia.org/wiki/Tree_traversal  See the psuedocode at the bottom.

[bruce]

Ginny.. yeah.. recursion. tower implementations.. .basic types of coding/logic issues..  Brings back memories of 1st year coding assignments multipe decades ago!!

However, what I'm facing isn't a recursive implementation.

 It's the kind of thing you'd see on any reasonable website where you drill down into a category/selection process.. and you then have the ability to also traverse back up the path/tree..

[ginnyjollykidd .]

That would be a recursion.  Remember hashing and hashpiles? They are data unconnected except for starting with one datum, then connecting two more to it to make a choice, then each connected to two, and so on till the last remaining data become widows, and any new data would attach to the windows and make the next levels of recursion.

The recursion code has a pointer figuratively find the bottom of each branch of the tree and compare each entry to what the program says it needs. It works backward, and when there is a branch that is unexplored yet, again the code has the pointer find the bottom of the branch and starts the search all over again till either the match is found or the whole hashpile is explored and a default error is reached saying the result is not there, and there are no entries left. (your basic 404 error).

This is my take on the pseudocode:
It would say, "is this the end, yet?" Y/N
If N, move down the left side of the pile one level
If Y, [entry comparison function.] If entry != conditions, move up one level of tree and move down the right side one level. Start again at first instruction.

Now all you need to do is convert that to code.

Ginny

[bruce]

Hi Ginny...

Not really recursion.

IE,

get dept "electronics"

  of electronics, get "tv"

    of tv, get sony

  so the page is essentially:

   master -> electronics -> tv -> sony

 at this point, the logic has stored whatever you need indexes, session vars, etc..

the issue now is how/what you need to do to let the user select electronics(and the link) to get back to the electronics page.. do you have/maintain a complete link for the "electronics" html, etc.. or is/are there other ways of implementation..

and at the same time.. are there better/worse libs for implementation.

this kind of thing has already been created millions of times..

at the same time, what's the "better/best" approach to setting up the db/tbl schema to handle millions of recs..
...

good back/forth though!!

thanks!

[ginnyjollykidd .]

Yes, you're right. Sounds more like a database function like MS Access is. And yes, it would be Sequel you'd use. I'd have to refer you to my mom for that, and she hasn't worked with that for about 15 years herself, since she retired. Sorry.
Ginny

[d.s.]

Bruce,

Pretty much every major web framework has some kind of a breadcrum implementation.

bootstrap: http://getbootstrap.com/2.3.2/components.html#breadcrumbs
angularjs: http://ncuillery.github.io/angular-breadcrumb/#/sample

jquery: http://www.ajaxblender.com/script-sources/xbreadcrumbs/demo/

For the implementation itself it depends on the behavior you want.

(Here are two example, things in stars indicates page that's currently visible)

master -> electronics -> tv -> *sony*

(click on electronics)
master -> *electronics* -> tv -> sony

master -> electronics -> tv -> *sony*
(click on electronics)
master -> *electronics*

In the first case that's actual breadcrum. You can go back and forth. The second case it's actually just a nav-bar.

what about hierarchy of the data: is it fixed? ie, is tv always going to be a sub-child of electronics, and sony is always a sub-child of tv?

The breadcrums where you can go back and forth can only be implemented with client-side javascript. You have to alter you breadcrum display in real time. So at this point you can decide if you want to encode the links or just specify links directly in the href. (direct links are always good for downgrading)

In the navigation case it's pretty simple, but you have to encode enough info into each link so that the server side knows where you are and where you want to go. Then when it generates the pages each link in the breadcrum link will have all the info on how to generate the list.

So here is what I mean. These are highly simplified example with three different pages. With how the crums' and links URLs will look like in a three page hierarchy.

page1:

<page1: /page1.html>

page2_link: /page2.html?crum=page1

page2:

<page1: /page1.html?crum=page1 page2: /page2.html>

page3_link: /page3.html?crum=page1&crum=page2

page3:

<page1: /page1.html, page2: /page2.html?crum=page1 page3:/page3.html>

page4_link: /page3.html?crum=page1&crum=&page2&crum=page3

The server-side can blindly process the crums params left to right and just generate list of links for your breadcrums for the current page. On the last link you strip out all parameters so that you refresh button doesn't get confused. But your history without some client-side java-script will look all funky.

But you can make each breadcrum contain extra data that can be handled by javascript to let it know how many pages in history to go back using the window.history.go() function.

Hope all that makes sense.

[d.s.]

(sorry I pasted old text in that email)

page1:

<page1: /page1.html>

page2_link: /page2.html?crum=page1

page2:

<page1: /page1.html page2: /page2.html?crum=page1>

page3_link: /page3.html?crum=page1&crum=page2

page3:

<page1: /page1.html, page2: /page2.html?crum=page1 page3:/page3.html?crum=page1&crum=page2>

page4_link: /page3.html?crum=page1&crum=page2&crum=page3

[Joe Ibershoff]

Yes, this sort of thing has been done many times before, but as is often the case, just because many websites present a similar UI to the user (a good idea, as it leverages a user's familiarity with e.g. breadcrumbs to make your site more intuitive) doesn't mean they implement it the same way behind the scenes.  The devil is in the details, and although you can hand-wave that for a simple example app, if you really want something that is a prototype for a real production site, then your choices will depend on things that are specific to your site.

Chorgy hit most of the points I was going to raise.  To put my own spin on them:

You don't want to try to "remember" where the user has been or is going -- as a best-practice, you want the server-side code, and if possible the browser-side code, to be "stateless".  The goal is to encode everything needed in the URL, whether it uses query parameters as in Chorgy's examples, or dynamic paths like "/products/electronics/tv/sony/".  The thing to think about is this -- if a user bookmarks your page after they've started navigating in (let's say they've already selected "electronics" and "TVs"), but then navigates around on your site more, eventually landing in a "cookware" section, then closes their browser, and the next day goes to that bookmark, will they wind up back on the electronics/TVs page?  Ideally, the answer should be "yes".  The only place this sort of thing should be "remembered" is in the URL of the current page, and the breadcrumbs are built based on the URL.

As for building the breadcrumbs, you can do that either client-side using one of the frameworks Chorgy listed, or server-side if you are doing server rendering of your pages.  (Although I'm not sure it can be called a best practice, the world is moving toward client-side rendering and away from server-side-rendered dynamic pages, so that's what I would suggest.)

Regarding schema best practices, I have similar questions to the ones Chorgy raised.

Is your schema a strict hierarchy?  Or is it possible to go to "electronics", then "computers", then "media PCs", and see the exact same list of products as if you went to "electronics", then "home theater", then "media PCs"?  Might you have products (perhaps a fancy induction cooktop like http://paragoninduction.com/) which falls under "electronics" as well as "cookware", or in such a case would you simply pick a single category to make things simpler?

Will the user be able to browse all products, or all electronics?  Or must the user always select a fixed number of options before they will see any results?  Is it ever possible to skip a level, e.g. view either "electronics -> TVs -> Sony" or "electronics -> Sony"?  Will all your products have the same fields regardless of category, or will the data need to be structured differently depending on the category?  That last one is a trick question, as you can have a JSON column in your db which holds data of differing structures, but used inappropriately it could really damage your db query performance -- a better question is whether users will need to be able to search based only on fields that are common to all products, or will it be important to be able to search e.g. TV's based on size and resolution when most of your other products won't have such fields.

Only after hearing answers to the above (and possibly more) questions could I suggest a specific schema.

[bruce]

Hey Joe.. and all the others who've chimed in!


The process that I'm looking at, is for a college, class/book process.

The rough tables are for the following areas/data, and in the tbls, the parent/child is/can be as listed below.

Some colleges might have a different parent/child tbl relationship but for the most part, the following four (4) relationships cover the overall process.

The idea, will be to then let the user be able to iterate/drill down in the process (as illustrated in the nav/breadcrumbs listed) to be able to to drill down, as well as go back/traverse back through the process. This would allow the user to then see the "previous" data from the previous levels.

Each tbl, has (or will have) an ID linking the parentTBL/childTBL, as well as a separate process/tbl, that links the parentTBL/childTBL levels. This allows the sql/logic to be able to generate the logic to get the required child/parent data based on a given item in a tbl..


So, more thoughts/comments on the breadcrumb/nav issues would be cool!

In fact, if anyone's interested, once this gets to the point where the underlying crawl is actually generating sufficient data for the colleges.. I can head over we can grill/pizza/etc.. and psuedocode!!

The goal is to have ~310 colleges with complete class/book data... If all of this works, the process can be expanded to ~500-600 colleges later...

tbls/relationship:: for the different colleges
============
state
  college
    campus
      dept
        class
          section
            book


state
  college
      dept
        class
          section
            book


state
  college
    campus
      dept
        class/section
          book


state
  college
      dept
        class/section
          book


------------------------------------------------

hierarchy/breadcrumb/navigation process
state / college / campus / dept / class / section / book

state / college / dept / class / section / book

state / college / campus / dept / class-section / book

state / college / dept / class-section / book

--

[ginnyjollykidd .]

I'm thinking that in every level you will need a pointer to each level you want, and to do that, on each page have a pointer to a side menu like department stores often have, and indeed my Alma Mater, UofL (louisville.edu) has. Then you can pick from a list of subjects, and if you want a different subject, the pointer for the list is on every page (like the set of horizontal lines box or an arrow button or an open button or the like) and the list flies out. Some, like Target, have a tree that flies out so you can see what tags are included in it.

So I'm thinking one of the functions would be to start with the address that all the pages point to, then it would be a list of pointers with each pointer having a list of pointers beneath that refer to that single department, thus:

Major index address
Tools address with value A
Hand tools sub value 1
Hammer sub sub a
Pliers sub sub b
Screw drivers sub sub c
Etc
Power tools sub value B
Sawzall sub sub a
Circular saw sub sub b
Power drill sub sub c
Etc.
It's in outline format, a format that I haven't seen required in school since eighth grade. Maybe high school once or twice, maybe English 101 once.

And all these would be one list of pointers each having the address of the page appropriate to the subject.

Now for the return trip if you have Tools > hand tools > hammer, then each entry refers back to the address of the pointer that led there, which, I think, would be a lot more coding (and a lot more tedious) than returning to function of the flyout page, which would require only one address to program.

Yours truly,
Ginny

[Greg Miller]

I hope you're not actually planning on having each category as its own table.  I have seen people do this thinking it's less work on the database, but it isn't.  The extra work the database does in finding the right table and associated files will at best equal the performance for keeping all of the categories in the same table.  In reality, you'll probably get a whole lot worse performance.  The database will use b-trees to organize the data in the tables, additionally it will also use a b-tree to organize the tables themselves, and lastly the file system will also use b-trees to organize the files on disk.  Essentially, "It's turtles all the way down".

The table should be structured similar to this:
ID   Parent    Category Name
0    null      Top Level
1    0         Electronics
2    1         TVs
3    2         Sony
4    2         Magnavox
etc.