Re: [greenstone-devel] Problems with CSS

From Michael Dewsnip
DateWed, 22 Aug 2007 09:59:59 +1200
Subject Re: [greenstone-devel] Problems with CSS
In-Reply-To (000001c7e080$bbcedac0$336c9040$-presno-infomed-sld-cu)
Hi Ileana,

I've had a look at the screenshots you sent but I still don't fully understand your problem. I think you are trying to format what is shown on the classifier pages -- is this correct? If so, the classifier nodes are controlled using the format statements in the collect.cfg file, not with macros. You probably need to change these format statements to get what you want.

If this doesn't answer your question please send a screenshot showing what you want the page to look like.

Regards,

Michael



Ileana Presno wrote:
Hello everybody:

In the last days I upgrade Greenstone version to 2.74. So, I was seeing the
new upgrades you made it and I notice that since the version 2.63 you can
work with CSS and that's is very useful. I was making some changes mainly
related with CSS. I modify the macro that I made long time ago for this
specific collection and I made too a CSS file to control my collection view.


I made a lot of changes and even that was sometimes tough to get the result
I was expecting I doing pretty well almost everything. But I'm still having
few problems when I tried to browse through the navigation bar to view the
content. My problems are mostly related with the information that I have to
see through the classifiers Title, Subject, Creators and Date. 

Most of my problems is with the information have to appear when I use this
buttons. Because when I tried to see this information I noticed that the
graphic design I made change. During the this week I tried to resolve this
but I don't know what else to do. I think the problem would be in the macro
I made, more specific could be inside this macro in the macro that control
the content. 

I'm sending in this email a print screen that shows the problems and the
macro and css of my collection. I hope someone can help me with this. I will
appreciate any help with this because I'm stocked right now.

Regards,

Ileana Presno

Collection Development Coordinator
INFOMED-CNICM
CUBA       

-----Mensaje original-----
De: greenstone-devel-bounces@list.scms.waikato.ac.nz
[mailto:greenstone-devel-bounces@list.scms.waikato.ac.nz] En nombre de
greenstone-devel-request@list.scms.waikato.ac.nz
Enviado el: viernes, 18 de mayo de 2007 22:45
Para: greenstone-devel@list.scms.waikato.ac.nz
Asunto: greenstone-devel Digest, Vol 50, Issue 2

Send greenstone-devel mailing list submissions to
greenstone-devel@list.scms.waikato.ac.nz

To subscribe or unsubscribe via the World Wide Web, visit
https://list.scms.waikato.ac.nz/mailman/listinfo/greenstone-devel
or, via email, send a message with subject or body 'help' to
greenstone-devel-request@list.scms.waikato.ac.nz

You can reach the person managing the list at
greenstone-devel-owner@list.scms.waikato.ac.nz

When replying, please edit your Subject line so it is more specific
than "Re: Contents of greenstone-devel digest..."


Today's Topics:

   1. Re: miscellaneous proposals (Michael Dewsnip)
   2. Re: Applying 2 interfaces to one Greenstone (2)collection
      (Richard Managh)
   3. Re: miscellaneous proposals (jens wille)
   4. Fwd: [greenstone-users] Cannot search and index (Sandar Win)


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

Message: 1
Date: Fri, 18 May 2007 14:28:44 +1200
From: Michael Dewsnip <mdewsnip@cs.waikato.ac.nz>
Subject: Re: [greenstone-devel] miscellaneous proposals
To: jens wille <jens.wille@gmx.org>
Cc: greenstone-devel@list.scms.waikato.ac.nz
Message-ID: <464D0F5C.1080004@cs.waikato.ac.nz>
Content-Type: text/plain; charset=ISO-8859-1

Hi Jens,

Almost all of your changes are in code that I wrote, so I guess I'm the
best person to take care of them :-)
  
now that our project draws near its end, i'd like to propose some of
the changes that i frequently apply to our greenstone installations.
maybe you can find one or another useful enough to include them in
the standard distribution. at least, that would save me the work ;-)

1. additional option 'partition_name_length' for GenericList:

  { 'name' => "partition_name_length",
    'desc' => "{GenericList.partition_name_length}",
    'type' => "string" }

pass $self->{'partition_name_length'} as second argument to
generate_partition_start/end calls. return early from those methods
if option is given:

  if ($partition_name_length) {
    return &unicode::substr($metavalue, 0, $partition_name_length);
  }

description (strings.properties):

  GenericList.partition_name_length:The length of the partition
  name; defaults to a variable length from 1 up to 3 characters,
  depending on how many are required to distinguish the partition
  start from its end. (only applies when partition_type_within_level
  is set to 'constant_size')
  
    
Seems like a useful option; I'll add it in.
  
2. commented out the following line (strip trailing whitespace; line
247 in current CVS HEAD) from GenericList, as this broke the UTF8
representation of, e.g., 'à':

  $metadata_value =~ s/s*$//;
  
    
Thanks for pointing this out; I'll try to find an alternative way of
doing this that doesn't mess up Unicode strings.
  
3. changed BasPlug.dummy_text to be *really* dummy, since the
provided text ("This document has no text.") leads to *illegal* hits
when searching for, say, "text":

  BasPlug.dummy_text:drthnmkiuhbvf.
  
    
I can see your point about the incorrect search matches, but I don't
think this is the right way to solve the problem because you sometimes
see this string when viewing the document. It would be better if the
plugin didn't add any text to the document, and the C++ code displayed
the "dummy text" string if necessary when outputting the document.

I don't have time to make this change; hopefully someone in the NZDL
Project can do it.
  
finally, there's a feature request that i didn't actually implement
yet, but that we could well use in our project. sometimes, when
using the "i'm feeling lucky" feature, we don't want to be directed
to the first result if there are in fact multiple results (we're not
feeling *that* lucky ;-). instead, we'd like to get the results list
just as usual in such a case.

i think, something like the following should do the trick (i'm using
an "ifl" value of 2 to differentiate from the normal behaviour; diff
is against current CVS HEAD):

--- snip---

*** src/recpt/queryaction.cpp~  2007-05-17 15:21:36.000000000 +0200
--- src/recpt/queryaction.cpp   2007-05-17 15:30:16.000000000 +0200
***************
*** 1523 ****
--- 1524 ----
+       if (args["ifl"] == 1 || (args["ifl"] == 2 &&
response.numDocs == 1)) {
***************
*** 1550 ****
--- 1552 ----
+       }
  
    
Good idea, I'll add this in.

All the best,

Michael

  

_______________________________________________ greenstone-devel mailing list greenstone-devel@list.scms.waikato.ac.nz https://list.scms.waikato.ac.nz/mailman/listinfo/greenstone-devel


-- 
DL Consulting
Greenstone Digital Library and Digitisation Specialists
contact@dlconsulting.com
www.dlconsulting.com