On Tue, Jan 24, 2006 at 11:22:40PM +0100, Armin Burger wrote:
>
> >> Silke Reimer wrote:
>
> >
> > Yes, you are right. BTW: We already contacted you last summer
> > (before this list existed) but never got an answer. Please don't
> > misunderstand: This is not an offence since I know the problem of
> > getting to many emails! It is just an explanation why we contact you
> > so late.
>
> I checked my mails on @libero.it and @gmx.net but I have not received
> any mail from you last year.
It has been my collegue Frank Koormann who wrote this email - but
never mind. It contains no additional information.
>
>
> >>> I18N:
> > Could you explain why? In my opinion there is no need to implement
> > an own infrastructure when gettext already has made this.
> >
>
> not every PHP has gettext installed and I also find the getext concept a
> bit complicated, so I never used it. I found it easier to work with
> simple database tables where I also could easily include additional
> entries, like an import of all European country names for instance with
> country ID as key.
>
>
> >>
> >>> Checkscale:
> >> I do not understand that. I thought pmapper displays all layers that
> >> have their scale inside the range defined by max/minscale, like
> >> Mapserver does.
> >
> > We experienced a different behaviour as described above. Indeed this
> > is a rather small fix.
> >
>
> I think I never got these problems, also until now I have not heard of
> this from other users.
To end this: I just will prepare the patch and then you can have a
look wether this has any effect or not.
>
>
> >>> Info-Results
> > We wrote a new class VQuery which displays the table vertially. It
> > has indeed been a littly tricky to get the HTML-snappets into the
> > right order but it still is feasable.
> >
>
> How does it look like, if you have 2 records? Below each other? Besides
> each other, or with tabs? I already mentioned this to Dennis Jan: Having
> more display methods makes it more difficult to combine all of them, or
> maintain them separately.
Two record are in two different columns leading two a table with
three columns: Attribute name, value1, value2.
Again: I wil prepare the patch then send it to you perhaps with a
screenshot to show how it looks like. Then you can decide whether
you want to include it or not.
>
>
> >>> searchlist:
>
> > Yes, but we thought that js_custom.php should contain the
> > functionality while all application specific values (such as
> > concret search places) should be in the config-directory. In my
> > opinion this is easier to maintain for the application admin since
> > he has only one directory which contains every configuration.
> >
>
> that could make sense. Mainly also if just the required files are within
> an application, the standard class files could be in a general directory
> for more than just 1 project. Also a not mentioned feature for the
> future, defining the location of the incphp directory eg.
OK. Then I make this patch ready as well.
>
>
> Viele Gr??e aus Italien. Armin
Gratie :-)
Silke
--
Silke Reimer : www.intevation.de/~silke | GISpatcher: www.gispatcher.de
Intevation GmbH: www.intevation.de | Thuban : thuban.intevation.org
Georgstr.4 : 49074 Osnabr?ck | FreeGIS : www.freegis.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://faunalia.it/pipermail/pmapper-users/attachments/20060125/93f20863/attachment-0001.pgp
