[ansel] Tree view mods

Heath S. Hendrickson heath at outerspaceconsultants.com
Mon Feb 23 11:43:12 PST 2004


Now I'm tracking with you.  I had avoided using the (+) (-) style as I 
was trying to not use DHTML (JavaScript) unless necessary, but it 
appears that it is now called for.  This also means that Chuck's desire 
to use Horde_Tree is in alignment with your vision for the layout.  I'll 
take a look at it again to see if I can make any more sense of how to 
use it than I could last time.

As for the graphic, I don't see a major problem with using the thumbnail 
image for the preview, but that's my opinion.  I guess if there are 
multiple preview images on the same page then load times might be a 
factor and I could see the benefit of the icon image.  I'm just afraid 
that it will make it more complex to maintain the images.  How are the 
thumbs and screen resolution images handled currently, meaning when are 
they regenerated (if ever)?  Is it as the result of any image 
manipulation function?  Then you'd have to extend all the functions to 
rebuild all three of the scaled images.

Ben Chavet wrote:

>
> I guess I envision a groupbyowner tree view to be something like this:
>
>     (-) [img] Parent Gallery
>      |---[img] Sub-gallery1
>      |-+-[img] Sub-gallery2
>      | |---[img] Sub-subgallery
>      |---[img] Sub-gallery3
>
> With a simular tree for each user with a nice header with the owner's 
> name.
>
> Then a non-groupbyowner tree to be something like this:
>
>    (+) User1
>    (-) User2
>     |---[img] Gallery1
>       |---[img] Subgallery1
>
> In other words, all of the groupbyowner trees bundled together into a 
> tree.  It
> could just be that we have different visions for the same idea.
>
I'm not sure that this is enough of a difference in the view to really 
warrant having two sets of code.  See my comment below about making the 
groupings more view independent.

>> The idea of an icon image is noteworthy, I'm just not sure how much use
>> a 20x20 version of a 3000x2000 image is going to be.
>
>
> Yeah, I thought about that after I had already sent my message.  20x20 is
> definitely too small, but perhaps some smaller version of the 
> thumbnail.  I'm
> just trying to think ahead.  I already have 60-70 galleries & that 
> would take a
> lot of screen realestate in a tree or list view.  As my gallery list 
> grows, it
> only gets worse.
>
>
> The problem I see arising with having a single preview image for a 
> tree is when
> a user gets to have a lot of galleries.  The tree may be taller than the
> browser window & to see the preview, you'd have to scroll back & forth.
>
This would be a problem for both GBO and non-GBO based views.  I think 
it may be worthwhile to try and make the view the same, just have 
different grouping.  That makes the code more understandable and 
maintainable down the road.  Simply implement a different sort mechanism 
for the gallery data prior to calling the view templates.  Then it would 
be fairly easy to implement a new grouping preference (say by subject or 
keyword or category...).  Unfortunately, this means that the existing 
views need to be recoded as there are two distinct templates for each 
grouping for each view.  This makes the current implementation hard to 
extend.

Thoughts?

heath



More information about the ansel mailing list