Custom ImageColumn and columns in general

[Yuval Greenfield]

Hi sqlkit,

Let's say I wanted to implement a subclass of ImageColumn which doesn't use thumbnails at all or has a separate base_dir for thumbnails. Is it possible to cause SqlTable to use it?

Also, I didn't want to modify my models.py file just to declare a varchar as an image widget so I did the following in my sk_gui.py:

    m = sqlalchemy.orm.util.class_mapper(models.Image)

    m.c.fpath.info = {

                      'render' : 'image',

                      'base_dir' : '/shared/thumbs/',

                      }

Is there a simpler way to do this?

I think these 2 questions are related as they both are about customizing the image widget.

Yuval Greenfield

[Alessandro Dentella]

Hi Yuval,

I'll start from the second question:

> Also, I didn't want to modify my models.py file just to declare a varchar as an
> image widget so I did the following in my sk_gui.py:
>
> m = sqlalchemy.orm.util.class_mapper(models.Image)
> m.c.fpath.info = {
> 'render' : 'image',
> 'base_dir' : '/shared/thumbs/',
> }
>

correct

> Is there a simpler way to do this?

no, I think this is clear and pretty simple.

> Let's say I wanted to implement a subclass of ImageColumn which doesn't use
> thumbnails at all or has a separate base_dir for thumbnails. Is it possible to
> cause SqlTable to use it?

Yes.

If what you need is just to declare a separate base_dir, you can do that in
your model or modifying the mapper as show above. So I guess you whant to
change the renderer or similar, and it's not straitforward.

You need to

* instantiate a CustomColumnImage (that in turn requires a Field)
* add it to the view [1]
* delete via std gtk means the column from the treeview
* set the correct sqlkit.fields.Field in t.gui_fields

a similar process is used in 'replace_column' method of the FilterPanel [2]
replace_column in the filter widgets's view:

col = columns.VarcharColumn(self.master, field_name, label, field=field)
t.view.treeview.remove_column(self.view.tvcolumns[field_name])
t.view.add_column(col, n)
t.gui_fields[field_name] = field

I hope that helps you

sandro
*:-)

[1] http://sqlkit.argolinux.org/sqlkit/advanced/views.html#module-sqlkit.widgets.table.columns
[2] http://sqlkit.argolinux.org/sqlkit/filters.html#filterpanel

>
>
> I think these 2 questions are related as they both are about customizing the
> image widget.
>
>
> Yuval Greenfield
>

> --
> http://groups.google.it/group/sqlkit

--
Sandro Dentella *:-)
http://www.reteisi.org Soluzioni libere per le scuole
http://sqlkit.argolinux.org SQLkit home page - PyGTK/python/sqlalchemy

[Yuval Greenfield]

On Fri, Jan 6, 2012 at 11:36 PM, Alessandro Dentella <san...@e-den.it> wrote:

 col = columns.VarcharColumn(self.master, field_name, label, field=field)
 t.view.treeview.remove_column(self.view.tvcolumns[field_name])
 t.view.add_column(col, n)
 t.gui_fields[field_name] = field


I hope that helps you

sandro
*:-)



[1] http://sqlkit.argolinux.org/sqlkit/advanced/views.html#module-sqlkit.widgets.table.columns
[2] http://sqlkit.argolinux.org/sqlkit/filters.html#filterpanel

Thanks, that did help a lot.

I see that there isn't a way to get results beyond the set limit. Would a patch that allowed pagination of filter/reload results be of interest?

 

http://www.sqlalchemy.org/docs/orm/query.html#sqlalchemy.orm.query.Query.offset

Yuval

[Alessandro Dentella]

On Sun, Jan 08, 2012 at 05:44:41PM +0200, Yuval Greenfield wrote:

> I see that there isn't a way to get results beyond the set limit. Would a
> patch that allowed pagination of filter/reload results be of interest?
>
> http://www.sqlalchemy.org/docs/orm/query.html#sqlalchemy.orm.query.Query.offse

Surely! I would really appreciate that! please make sure to make it against
the last mercurial release, rather than the last rel.

thanks

sandro
*:-)

[Yuval Greenfield]

On Sun, Jan 08, 2012 at 05:44:41PM +0200, Yuval Greenfield wrote:

> I see that there isn't a way to get results beyond the set limit. Would a
> patch that allowed pagination of filter/reload results be of interest?
>
> http://www.sqlalchemy.org/docs/orm/query.html#sqlalchemy.orm.query.Query.offse

I'm glad that you like the idea. Well, there are a few options on where to put it:

1. Status bar - Add 3 editable textboxes (eg "1 - 20 of 4234" where you can edit the "1" and "20")
2. Next to the reload button.
3. Only in the filters window.

Either way I think it's only relevant to the table widget.

What do you think?

Yuval Greenfield

[Alessandro Dentella]

On Wed, Jan 11, 2012 at 04:28:56PM +0200, Yuval Greenfield wrote:
> On Sun, Jan 08, 2012 at 05:44:41PM +0200, Yuval Greenfield wrote:
>
> > I see that there isn't a way to get results beyond the set limit. Would a
> > patch that allowed pagination of filter/reload results be of interest?
> >
> > http://www.sqlalchemy.org/docs/orm/query.html#
> sqlalchemy.orm.query.Query.offse
>
>
>
> I'm glad that you like the idea. Well, there are a few options on where to put
> it:
>
>

> 1. Status bar - Add 3 editable textboxes (eg "1 - 20 of 4234" where you can

> edit the "1" and "20")

> 2. Next to the reload button.
> 3. Only in the filters window.

I dont' have yet a strong opinion... all the 3 options have some appeal.

You're suggesting to add 2 textboxes: start and stop, while now we already
have the LIMIT that maps more simply to a "paginate by" and a 'next page'
would probably be usefull.

I'm trying to think how I would use it. I'd probably use it paginating one
page at a time and not stepping in a particular one. With the 2 textboxes you
should probably change them by hand. What I mean is that the '20' in the
example should just be the same textbox that now limits. It would probably
mean 20 results starting from 1. It seems lesss readable probably, but would
retail the already present textbox with the same meaning.

So one (further?) proposal could be to

* add a "next page" button close to "reload"
* allow fine tuning the limit/offset in the filter
* user status bar just as explanatory (ok: "1 - 20 out of 4234" but w/o text
input)

Which is your preferred solution?

> Either way I think it's only relevant to the table widget.

Techically it shouldn't be different to add the same pagination to mask
view: the reload machinery is just the same.

The reason for doing it could be that some time you can have the filter
widget enriched with some more fields and in that particular view it could
be nice to be able to paginate: the filter widget becomes just a "table
view" (it's really a sqlkit.widgets.table.column.View object) of the
retrieved objects.

[Yuval Greenfield]

Your suggestion sounds perfect to my ears. Just keep the limit box and add a next button near reload while updating the status bar with the specific state.

The only problem would be that it's hard to reach the end/middle of a long list. But then again, maybe the user should refine/reorder their query in that occasion.

--
http://groups.google.it/group/sqlkit

[Alessandro Dentella]

On Wed, Jan 11, 2012 at 09:53:38PM +0200, Yuval Greenfield wrote:
> Your suggestion sounds perfect to my ears. Just keep the limit box and add a
> next button near reload while updating the status bar with the specific state.
>
> The only problem would be that it's hard to reach the end/middle of a long
> list. But then again, maybe the user should refine/reorder their query in that
> occasion.

I agree, I did think at that but w/o any ready solution. Some more ideas,
take them just as brainstorming, points 1. and 2. addresses this issue:

1. the "Go" menu could have a menu entry to step 10 pages ahead or a
percentage. This wouldn't add buttons that would be used very seldomly,
but still leave the possibility to accelerate browsing

2. a right click on the "Next Page" could be bound to 10 page step. This is
more criptic, but could be and "advanced" tip and newomers could anyway
used point 1.

3. netx/prev page: in table view that could just be exactly the same arrows
that in mask view mean "next record", "prev record". This would
introduce an important difference: "Next page" requires getting new data
from the db, while "next record" does not necessarily require that
(depending of which related attributes you show)

4. Clearly totals/subtotals will only act on the data that are being
displayed

[Yuval Greenfield]

On Thu, Jan 12, 2012 at 12:40 PM, Alessandro Dentella <san...@e-den.it> wrote:

 2. a right click on the "Next Page" could be bound to 10 page step. This is
   more criptic, but could be and "advanced" tip and newomers could anyway
   used point 1.

Right click on "next page" could actually act like "jump to " in a text  editor where a dialog appears asking which offset to go to.