lenya-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pankaj Mandaliya" <pankajmandal...@gmail.com>
Subject Re: Lenya customization - split main region area into two
Date Wed, 16 Jul 2008 11:17:09 GMT
Thanks a lot Andreas and Solprovider,

You have given very vital information.
Basically, my glossary is not as small as word definition, it can have some
explanation with graph for the keywords and more details, and it (link) has
to be controlled by editor the page. But, I would try out based on your
Currently, I got stuck with other activities, will let you know what I tried
out and if something useful comes out of it.

Thanks again,

On Sat, Jul 12, 2008 at 2:02 AM, <solprovider@apache.org> wrote:

> On 7/10/08, Pankaj Mandaliya <pankajmandaliya@gmail.com> wrote:
> >  In Lenya, we have the main body region, where we create XHTML document
> in
> > authoring mode and create articles. I want to create article which
> contains
> > a link, and clicking on this link, that article should be divided into
> two
> > separate parts. Here left part will still contain original document, and
> the
> > right part will contain the article referenced by left side document.
> >
> >  If in my article, there are some difficult words, which requires some
> > explanation, then instead of redirecting user to another page for that
> > word-reference-link, I want to present that information on the same page,
> by
> > splitting the original page into two and word reference information on
> the
> > right side. And I want my user to build such pages and create
> > word-reference-link like this.
> >  Pankaj
> For any functionality, start with the desired results.  Prototyping
> this functionality in HTML with a few definitions specifies the HTML
> and Javascript before creating the XMAP and XSLTs to integrate with
> Lenya.  Most of this post applies to any Web application.  Decide what
> the page should contain, then teach the system how to create that
> page.
> You want:
> 1. Words (links) that activate definitions.
> 2. A place to show the definitions.
> In ancient history (mid-1990s), this would be handled with FRAMEs.
> This method is highly discouraged today as ugly and
> less-than-user-friendly.  The rest of this post ignores this method
> Methods for showing the definitions:
> 1. HTML-only: Clicking a link refreshes the page with the definition shown.
> 2. Javascript: Clicking a link displays the definition without
> refreshing the page.
> 3. Javascript MouseOver: Show the definition when the mouse is over a
> highlighted word.
> Places to show the definition:
> 1. Defined area of page.
> 2. Defined area of page offset from current top of screen so the
> definition is forced into the viewable area.
> 3. In-page popup near the linked word, usually slightly below the
> word.  Best used with MouseOver triggering method.
> Methods for deciding glossary words:
> 1. Require the content editor to add links.
> 2. Use XSL to make every word found in the glossary into a link.
> 3. Use XSL to make the first occurrence of each word in the glossary
> found in the content body into a link.
> 4. Use JavaScript to make every word in the glossary into a link.
> 5. Use Javascript to make the first occurrence of each word in the
> glossary into a link.
> Creating the links can be handled by XSL or JavaScript.  XSL is better
> if editors must choose the words to become links.  Automating the
> process can use either method.  JavaScript's advantage is less
> server-side processing offset by more development and support work
> because Javascript often has browser-specific issues.  Using XSL
> requires one additional Transformation; using cache should remove any
> effect on performance.
> I discourage asking content editors to specify on each page where
> links to the glossary belong -- if they know a definition is needed,
> they should include the definition in the text.  Automating the
> process has several benefits:
> - New terms are used without editing existing content.
> - Content editors can ignore defining difficult terms on every page,
> - Content editors do not need to check whether a word is in the
> glossary while editing.  Publishing the page shows which terms are in
> the glossary.  Returning to the first benefit, adding a new term
> automatically updates the page without additional work
> Lenya-based technical methods for adding definition(s) to page:
> 1. For the HTML-only method, the linked word would probably be in the
> querystring.  Lenya looks up the word in the glossary and aggregates
> the definition into the page.  The same code should be used with or
> without the definition -- aggregate an empty definition when no word
> is specified in the querystring.
> 2. For other methods, all definitions need to be included with every
> page.  Now choose whether the content is presented as a DIV or set by
> Javascript:
> A. <div id="glossary-myword">"myword" is a word in the glossary</div>
> B. glossaryObject['myword'] = '"myword" is a word in the glossary.';
> The former is better when the DIV has a static location, just hide the
> previous DIV with display="none" and show the desired DIV with
> display="block" (or "inline".)
> The latter is better for dynamically creating the DIV with Javascript.
> Lenya can dynamically create the glossary when creating each page.
> Better performance is gained by updating a cached glossary pagelet
> when a glossary document is created or changed -- saving a definition
> updates a separate document aggregating all the definitions so normal
> page creation only aggregates that page.
> Maintenance of the glossary should be separated from maintenance of
> the content.  In Lenya, this is usually handled with a doctype.  The
> edit screen should alphabetize multiple terms and show the terms and
> definitions fields in a two-column expandable table.  Whether the data
> is stored in one document or many single-term documents is a design
> decision.  Single-term documents could be more scalable -- less
> conflicts when multiple editors are working at the same time if only
> changed terms are saved, but requires more development and server-side
> processing.
> HTH,
> solprovider
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
> For additional commands, e-mail: user-help@lenya.apache.org


View raw message