Forum OpenACS Q&A: Re: Portlets, Includelets and bright ideas!
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
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.
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
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
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.
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
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!
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...
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
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}
