Forum OpenACS Q&A: Re: Portlets, Includelets and bright ideas!

Collapse
9: Re: Portlets, Includelets and bright ideas! (response to 7)
Posted by Richard Hamilton on 09/30/09 12:44 AM
Gustaf,

Although I have read all the documentation I can find about XoWiki, I remain a little unclear as to how I go about creating what in ETP would have been called 'custom applications'.

I'd like to set up a series of page types that are highly specific for a particular html/css page design so that users can edit their pages without having to see or understand the html underneath it.

For example, let's say we have to convert a highly specific existing design into an XoWiki based CMS. A design that is completely fixed in size, bounded on all four corners by a fixed border, with a product image display window containing up to five product images, with css pseudo-classes making child div blocks visible elsewhere on the page. Oh, and a css driven drop-down menu system to boot!

For this example I would need a form that had a banner photo upload field, a footer image upload field, five product image upload fields, five product info text fields, a title field, and a field for the single paragraph of sales blurb per page.

I'd ideally like to do this without customising any of the underlying OpenACS code, and want to be able to eliminate the default site name, members online and log-in components of the master template. In other words I need one instance of XoWiki to have control of the entire browser window, whilst the rest of the OpenACS site functions normally.

In the past with stuff like this I have hacked away at the templates and the tcl where necessary, but I am searching for a better way with XoWiki.

Regards
Richard

Collapse
11: Re: Portlets, Includelets and bright ideas! (response to 9)
Posted by Gustaf Neumann on 09/30/09 02:12 AM
One can get full control over the browser window by using
https://openacs.org/xowiki/learning_content_tool?master=0 (compare with https://openacs.org/xowiki/learning_content_tool). In order to create a series of pages, i would recommend to use an ::xowiki::Form and define the content-fields as necessary. You can add a {{set-parameter master 0}} to the template part of the form. Look for example at the prototype pages "news-item" (defined the form) and "news" (summary page of news-items). I guess, you have seen already http://alice.wu-wien.ac.at:8000/s5-xowiki-tutorial/slides

In case, the entries of your "series of pages" have a state (e.g. a publishing workflow, different stages on a an entries life cycle, etc.), once can use xowiki content flow, where one workflow-definition can group all workflow instances. This is similar to the relation between ::xowiki::Form and an ::xowiki::FormPage, but with the workflow, every entry might have a different form in different states (see e.g. http://nm.wu-wien.ac.at/research/publications/b765.pdf)

Collapse
12: Re: Portlets, Includelets and bright ideas! (response to 11)
Posted by Richard Hamilton on 09/30/09 01:26 PM
Gustaf,

Thank you for those two pointers, that is enormously helpful.

Now that I know that this is the correct direction, I can immerse myself in it without fear that my efforts will prove fruitless!

Regards
Richard

Collapse
13: Re: Portlets, Includelets and bright ideas! (response to 11)
Posted by Richard Hamilton on 09/30/09 01:43 PM
Gustaf,

I had not in fact found those two documents you referred to so that you for providing the references. I will study them, they seem to cover precisely the things I want to try.

Thank you,
Richard

Collapse
14: Re: Portlets, Includelets and bright ideas! (response to 11)
Posted by Richard Hamilton on 11/19/09 01:30 PM
Gustav,

Once I have created my ::xowiki::Form with the appropriate fields in it, where do I put the enclosing markup?

For example, suppose I have an OpenACS 5.5.1 installed with the site default page re-directed to the xowiki page called myindexpage which was created by completing the content entry form. This page is displayed with master=0.

I have no markup in the entered content. I am not wrapping the page in oacs site navigation (i.e. master=0). Where is the correct place to put (for example) a set of containing div blocks, a header, a menu bar and a footer? Do I have to hack at the default xowiki adp templates or is there an elegantly abstracted way to do this?

I realise that I can create a style sheet, enter it into the xowiki and refer to it, but what I am wondering is where the structural html to which that css will be applied should go?

Regards
Richard

Collapse
15: Re: Portlets, Includelets and bright ideas! (response to 14)
Posted by Richard Hamilton on 11/22/09 11:27 PM
Gustaf,

Ok, WOW! I think the penny has dropped. Please disregard previous question.

I need to start experimenting! 😊

Once I have done so I think I might put together a brief step by step guide to entering a simple form spec and aesthetic design template to hand-hold through the initial process.

I was still in the mindset that I might have to write some .adp templates to surround the form fields in the final output, just as in the ETP application. I now realise that you have made the entire process dynamic! That was a dream documented about 5 years ago or more when Lee was writing the dynamic types package.

I see that you have made that dream a reality. Now all I have to do is learn how to use it!!

😊

R.

Collapse
16: Still struggling with xowiki. (response to 15)
Posted by Richard Hamilton on 11/25/09 02:27 AM
I have an html template for a set of pages on a site, styled with a style sheet, into which I can simply place text and image references in order to create a sequence of similar pages with different content and all laid out the same way.

I have edited that html and substituted all the sequences of text with @suitably_named_var@ and all references to images with @suitably_named_img_var@.

I have clicked to 'add' a new xowiki::Form and have attempted to paste the resulting html+vars into the template field. On submit xowiki tells me that 'The attribute 'class' is not allowed for div tags'.

Am I on the right track here or completely missing the point? Although I have read the docs fully, I am also still not exactly clear what for example the 'Section' field is for, what 'Autoname' will do for me, whether I need to complete the form field or if xowiki will autogenerate a form for all unknown vars, and what 'Page Title' might mean for arbitrary xowiki objects (i.e. form intended to be a page template for creating other pages).

Sorry to be thick, but until I actually manage to enter something, I can't really experiment.

I feel as if there's a whole wide world out there if only I can get over the wall to start exploring it! :-|

Regards
Richard

Collapse
17: Re: Still struggling with xowiki. (response to 16)
Posted by Gustaf Neumann on 11/25/09 09:36 AM
Dear Richard,

Concerning 'The attribute 'class' is not allowed for div tags': Until Aug. 10, side-wide admins and package admins were allowed to enter 'insecure' HTML tags. Since this date, it is not allowed anymore. Since xowiki uses the standard HTML validation of acs-templating, this effects xowiki contents as well. AFAIK the problem was that an admin (package- or side-wide-admin) was able to enter e.g. a CSS class in an xowiki page, but an ordinary user was not allowed to change this page, "not even to fix a typo" (ask michael steigman for the details). So they decided it is better that no one can do it.

The main problem was most likely that the change was effecting all packages. The old change of mine was discussed with the oct years ago but reverted at Aug 10 http://fisheye.openacs.org/changelog/OpenACS/?cs=oacs-5-5%3Amichaels%3A20090810183511

It is certainly possible to program around this in xowiki, at least for forms. As you point out, xowiki-forms are rather limited in its power with the standard settings. I have not updated acs-templating on our installations after the change above. However, since the dangers of editing a CSS class of a page are rather limited you could add "class" to the AllowedParameters in the kernel parameters on your installation.

Concerning 'Section': see http://alice.wu-wien.ac.at:8000/xowiki-faq/#page_order
The page orders are available for all kind of pages, therefore for forms as well.

Concering 'Autoname': This field is used for controling whether "instances" of this form will be autonamed or not. If you have e.g. a form named Person, and you enter a person (an "instance", the first person will be named person1, the next person2, etc.

Hope, this helps
-gustaf neumann

Collapse
18: Re: Still struggling with xowiki. (response to 17)
Posted by Richard Hamilton on 11/25/09 12:16 PM
Gustaf,

Thank you for the reply. After posting last night, but before turning in(!), I managed to work out that I needed to add 'class' to allowed attributes, and 'IMG' to the allowed tags in the kernel paramaters in order to upload my code.

This at least allowed me at last to see the autogenerated forms and to try an xowiki::Form and an xowiki::Template.

I learned that I have to be careful with naming since every single variable specified must have a unique name which I presume is requirement imposed by the CR data model.

I have seen the 'import' button on the admin page which I presume will allow me to import some of your example form definitions. Hopefully these will allow me to see your form defs and work out how to do it.

Am I correct in thinking the following:

- The template field is for adding html/css markup that styles and lays out the page? There is an option to include @vars@ in the template which will be substituted for entered values when an instance of the form is rendered.

- The form field is optional and is for writing forms explicitly rather than relying on the automated form generation. This presumably is an interface to ad_form? I think that this field may be left blank if the auto generated form is adequate for the purpose. I am not clear on the syntax and semantics for entries in this field. I think this field would be used to for example specify that a textarea entry widget should be for example 80x10 rather than the default size, or to set styling.

- The constraints field is optional and is for specifying constraints in an exactly similar way to those specified for ad_page_contract?

I have created an initial test form that allowed for every content element of my page to be entered in a field. Whilst this eliminates the need for markup to be edited, it results in a huge form with over 20 fields to complete. I would therefore have to decide whether it is a good idea to do this, or whether the simple option of adding the content as markup is actually better and more flexible in the long run.

I have had to produce a simple CSS driven dropdown menu (don't you just hate designers!) which will appear on every page. Am I correct in thinking that I can create an xowiki page for this, and simply include it in the html template at the appropriate point so that it would only need to be edited once to reflect on all pages?

Sorry to ask so many questions.

R.

Collapse
19: Going great guns now! (response to 17)
Posted by Richard Hamilton on 11/25/09 06:57 PM
xowiki::Form is now working a treat. Thank you Gustaf.

I have a question about wiki page includes.

I have implemented a dropdown menu using an unordered list and CSS pseudo-classes.

I want to have the menu as an xowiki page object so that I can include it 'inline'. This would avoid having to edit every page as a change to the master menu page would then be reflected in all other pages that use it.

I have tried to do this using {{en:mymenupage}} but this renders the page as a link inside what looks like a portal.

How to I tell xowiki that I want this page fully rendered 'inline'?

Regards
Richard

Collapse
20: Re: Going great guns now! (response to 19)
Posted by Richard Hamilton on 11/26/09 12:04 AM
I had been fighting shy of developing a fully integrated dropdown menu because I thought that the categories includelet was spitting out lots of javascript and my menu works with CSS pseudo-classes which I prefer.

Imagine my delight when I discovered that Gustaf's categories includelet delivers the data in precisely the same structure as I use - as an unordered list.

All I need to do is adapt my CSS and I should be in clover!

Collapse
21: Re: Going great guns now! (response to 19)
Posted by Gustaf Neumann on 11/26/09 01:34 PM
Concerning "How to I tell xowiki that I want this page fully rendered 'inline'?"

Use e.g. {{en:mymenupage -decoration none}}

In additions to the decorations listed in http://alice.wu-wien.ac.at:8000/xowiki-doc/#predfined_includelets newer xowiki versions have additionally a "-decoraton edit".

i have the impression, that you have figured out the answers to the other questions yourself...

Collapse
22: Re: Going great guns now! (response to 21)
Posted by Richard Hamilton on 11/26/09 09:46 PM
Gustaf,

Yes, thank you. Once I managed to find your examples to import I was away! I saw the -decoration none directive to the includelets in the docs, but nothing specific to the included wiki pages. I eventually concluded that this probably also worked for wiki pages as you have confirmed, {{en:page -decoration - none}}, however by that stage I had decided to bite the bullet and dive into making the menu system I have been forced to produce, work with the categories includelet!

I have done so, but want to suggest an ammendment to the <ul> that the includelet produces that will enhance its utility and interoperability with CSS.

I have been forced by a design to produce a horizontal menu with dropdowns. This requires the CSS selectors to be able to distinguish the top level list and display it 'inline', whilst all subsequent lists are displayed as 'block'.

The issue is that if you render the submenus as blocks, they are displayed as blocks inline to the top level list. This unrecoverably upsets the position of the subsequent inline top level menu items. The ONLY way to avoid this is to take the submenus out of the normal flow by using position: absolute. However if you do this without a containing <div> all the menus sit on top of one another adjacent to the left hand margin of the last absolutely positioned block element.

I therefore propose that every <ul> that is a child of <ul class="mktree"> be wrapped in a <div class="mkbranch"> or other suitable classname. The reason this works is that the <div> when set to position: absolute; width: 100% will sit beneath, and only be as wide as, the top level <li> that is its parent. You can then relatively position the <ul> submenu within the div block, without upsetting the top level menu item display flow.

I have posted below an example of the menu and the CSS. I realise that this is a specific applicaton for me, but this small change to the categories includelet itself would increase its flexibility, which surely can only be a good thing. I think this would add potential without breaking anything (although I confess I haven't studied the oacs-view template for the gory details of the treeview code). At least I would hope any change to that would be trivial.

The code posted below has taken quite a bit of time to get right, so I hope it will prove useful to anyone else who has to consort with the evil forces that demand horizontal drop-down menu bars! 😊 A bit of a fantasia on the use of CSS pseudo-classes.

Regards
Richard

Collapse
23: Code for previous posting. (response to 21)
Posted by Richard Hamilton on 11/26/09 09:58 PM 
Sample Categories Structure HTML
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

<!-- Menu System Structure -->

<div class='categories'>
  <div class='portlet-wrapper'>
    <div class='portlet-header'>
      <div class='portlet-title-no-controls'>
        Categories
      </div>
    </div>
    <div  class='portlet'>
      <h3>Contents</h3>
      <ul class='mktree' id='Contents'>
        <li class='liClosed'>Tree Name
          <ul>
            <li class='liItem'><a href='/xowiki/forum'>item1</a></li>
            <li class='liItem'><a href='/xowiki/index'>item2</a></li>
            <li class='liClosed'>
              item3 
              <div class="submenu">
                <ul>
                  <li class='liItem'><a href='/xowiki/one'>one</a></li>
                  <li class='liItem'><a href='/xowiki/two'>two</a></li>
                  <li class='liItem'><a href='/xowiki/three'>three</a></li>
                  <li class='liClosed'>four
                    <div class="submenu">
                      <ul>
                        <li class='liItem'><a href='/xowiki/first'>first</a></li>
                        <li class='liItem'><a href='/xowiki/second'>second</a></li>
                        <li class='liItem'><a href='/xowiki/third'>third</a></li>
                        <li class='liItem'><a href='/xowiki/fourth'>fourth</a></li>
                        <li class='liItem'><a href='/xowiki/fifth'>fifth</a></li>
                        <li class='liItem'><a href='/xowiki/sixth'>sixth</a></li>
                      </ul>
                    </div>
                  </li>
                  <li class='liItem'><a href='/xowiki/five'>five</a></li>
                  <li class='liItem'><a href='/xowiki/six'>six</a></li>
                </ul>
              </div>
            </li> 
            <li class='liClosed'>
              item4 
              <div class="submenu">
                <ul>
                  <li class='liItem'><a href='/xowiki/another'>another</a></li>
                </ul>
              </div>
            </li>
          </ul>
        </li>
      </ul>
    </div>
  </div>
</div>

<!-- End of Menu System -->


CSS Classes Invoking Singing AND Dancing Bears
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

/* ################### */
/* Menu system classes */
/* ################### */


/* Set the style for links on the menu bar */
div.categories a:link {font-family: "Segoe UI", arial, sans-serif;
                       font-weight: bold;
                       font-size: 11pt}

/* Set style for visited links on the menu bar */
div.categories a:visited {font-family: "Segoe UI", arial, sans-serif;
                          font-weight: bold;
                          font-size: 11pt}

/* Vanish the bits of the OpenAcs Category tree that we don't want */
div.portlet-header {display: none}
div.portlet > h3 {display: none}

/* Hide top layer of Category tree by fiddling with font size */
div.portlet > ul.mktree > li.liClosed {font-size: 0pt;
                                       list-style: none}

/* Have to immediately reset explicitly to size required for menu bar */
div.portlet > ul.mktree > li.liClosed > ul {font-family: "Segoe UI", arial, sans-serif;
                                            font-weight: bold;
                                            font-size: 11pt;
                                            overflow: visible}
/* Use to set position of menubar */
div.portlet {position: absolute;
             width: 70%;
             top: 110px;
             left: 5px;
             margin: 0em;
             padding: 0em;
             color: #6d6f71;
             opacity: 0.85;
             z-index: 1}

/* The addition of this <div> is unavoidable because with a horizontal menubar */
/* you have to take the dropdown out of the flow whilst preserving its position */
/* relative to the top level option selected. A <div> block allows for relative */
/* positioning without upsetting the flow of the horizontal elements.           */
div.submenu {display: none;
             position: absolute;
             width: 100%;
             left: 0px;
             margin: 0em;
             padding: 0em;
             overflow: visible;
             color: #4a9a44;
             background: #ffffff;             
             -moz-border-radius: 12px;
             z-index: 1}

/* Make sure that the first layer is displayed horizontally */
ul.mktree > li > ul:first-child > li {position: relative;
                                      top: 0px;
                                      left: 0px;
                                      display: inline;
                                      padding: 2px 20px 5px 20px}

/* All subsequent descendents are block displayed submenus */
div.submenu ul {display: block;
                list-style: none;
                position: relative;  
                width: 70%;                                                 
                left: 0px;
                top: 0px;
                padding: 2px 0px 2px 0px;
                margin: 10px 20px 10px 20px;
                line-height: 0.9em;
                text-align: left;
                color: #4a9a44}

/* Adjust gap between seperate <li> entries, but not between wrapped entries */
ul.mktree > li > ul:first-child > li div.submenu > ul > li {margin: 12px 0px 12px 0px} 

/* Add in the horizontal menu item separator bars */
ul.mktree > li > ul:first-child > li +li {border-left: solid 2px;
                                          border-color: #4a9a44}
                
/* The following pushes sub-sub-menus to the right and down slightly*/
div.submenu div.submenu {left: 99%; top: 36%}

/* The following makes the menus appear when the mouse moves over the items */
li:hover > div.submenu:first-child {display: block}