Forum OpenACS Q&A: Re: Still struggling with xowiki.

Collapse
Posted by Gustaf Neumann on
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
Posted by Richard Hamilton on
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
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
Posted by Richard Hamilton on
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
Posted by Gustaf Neumann on
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
Posted by Richard Hamilton on
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
Posted by Richard Hamilton on
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}