schooltool-developers team mailing list archive

[Justas <justas@xxxxxx>]

Hi,

Found some interesting discussions on IRC last night, here are my two cents.

<replaceafill> <div class="refine" tal:define="refine 
view/providers/page_refine|nothing"
<replaceafill>      tal:condition="refine">
<replaceafill> i guess this way forms don't have to subclass expanded 
page anymore just to get rid of the sidebar
[and relate NoSidebarPage discussion]
...
<replaceafill> changes pushed to trunk: "Changed ExpandedPage class name 
to NoSidebarPage. Also conditioned sidebar rendering"

(disclaimer - I didn't look at those changes yet)

I don't think we need a separate template that is identical but
without a sidebar.  But we do need a template where the content area
is wider, say, ~900 px wide (leaving no room for sidebar).

The simple page template should render everything, but if there is no
sidebar provider *or* it is empty, it should do whatever it needs to
do to display empty space where sidebar should be (there's probably a
bug there currently).  Thus, if page_refine provider (or some other
viewlet manager) does not have viewlets it should render to an empty
string.

The "expanded" template is for exceptions like gradebook or journal,
*if* we just can't fit the content into 544px.

To summarize - I don't like the "NoSidebarPage" name, because it's
purpose should *not* be removing a sidebar, but to give more
horizontal space for large content.


<th1a> Is it too late to just change that replaceafill?
<th1a> It is pretty confusing.
<replaceafill> th1a you mean the class name?

It's a good time to do that.  Maybe change to "page_sidebar" for
provider, "sidebar" for css class?


<aelkner> replaceafill, are breadcrumbs in a state of flux?

The plumbing is done (probably did not foresee some scenarios
though), we'll have to go over the implemented pages later on, and
just set them right.

Vitor gave me an impression that this is often a case of fine-tuning -
whatever is reasonable for the user as opposed to data model - hence
the implementation is more manual than automatic.  Also oriented on
fine-tuning per-view, you can change any part of the breadcrumb path
for specific view(s).


[on discussion about "demographic" field reordering]

Maybe we can split the functionality to "create/delete" and "reorder"
views - "reorder" being a modal view were user can play with jquery
sortable draggable list, then hit "Done", "Cancel" or close the
dialog.  And one write to database on "Done" as opposed to write each
time any item is moved.  But this is just a random idea.


<replaceafill> use <table class="demographics-reoder-table">
...
<aelkner> what's with the minus signs, btw?
<aelkner> replaceafill, do you realize that if we don't keep consistent 
with using _ or -

z3c.form and jquery use dash(-) for css classes, even formlib.  If we
want consistency, we should use dashes to.


<replaceafill> do we really need <tal:dummy condition="view/update"> 
</tal:dummy> in the new templates?

No.  When you "flourish" a page, please don't paste those!  This was a hack
so that update got called when rendering a view (and we were to lazy
to call that from python).  Flourish pages/viewlets/everything_else
has built-in proper upate/render handling.

Cheers,
Justas