I would like t o quote a famous Dutch soccer trainer
Translated into English it would be something like:
Am you so dumb or am I now so smart?
I have read some tutorials about XPages and I have started with upgrading an existing Domino application with XPage technology. Basically I want to display documents with an XPage instead of a web enabled Form.
I have some nice center layered container layout with sections for a header, leftside menu, main and a footer. With a bit of help of CSS it looks fine. Now I have started to transform the subforms into custom controls and the structure of the Form into an XPage. In stead of DIVs I am using Panels (I should or not?).
First thing I notice that panels in XPage technology only can get a name, when rendering this will be transformed into an ID. I have added my CSS for now in several files, later I will merge them together. For now for each custom control I have a CSS file attached to it.
What is happening is that the CSS get rendered well in Designer but when I look at the XPage in a browser the styling iscompletely gone! If I check in the source I see that all the ID’s have been modified, so I wonder if my CSS is still valid?
For example the original code:
<xp:panel id=”headerContainer”>
<xp:panel id=”headerLogo”>logo</xp:panel>
<xp:panel id=”headerName”>application name</xp:panel>
<xp:panel id=”headerSearch”>searchform</xp:panel>
</xp:panel>
get’s rendered as:
- Uhm, can somebody explain how to correctly code my CSS? (it is being loaded).
- Why have they done this? This makes converting current Domino applications into copy & paste & ready to run XPages enabled applications time consuming.
- I guess the reasoning behind it is not logical for normal web developers so it makes the adaption of Domino harder for them.
Here how it looks:
In Designer (CSS is working):
In Firefox:
After an x number of years working in the same environment I have decided to look for a new challenge. Are you looking for a smart companion?
Paul T Calhoun said
XPages can include other XPages. To this end to ensure that there is no namespace collision on control names all of the controls are prefixed with the view id’s when the page is rendered. This is why it works in designer but not the browser.
The easiest way to control this is to use CSS class definitions instead of referencing the tags ID attributes.
quintessens said
but isn’t that against the whole principle? and id should be used to a unique element that appears only once and a class for elements that appear more than once?
I guess I shouldn’t use panels here but stick with the old ‘divs’. Ican not say that the XPage editor is my favourite WYSIWYG editor…
Steve Castledine said
If you need your id’s to stick for CSS reasons etc just go into source and add the div’s yourself instead of using a panel.
quintessens said
hej Steve, yes I understand that. But still I think it is stupid giving an element an ID which will change at rendering-time.
Stephan H. Wissel said
The ID you give an element is unique and valid in the local context of the design element. Since any custom control and XPage can be mixed in various ways the JSF container needs to ensure ID uniqueness. The ID will always be the same in the same context (when you load the page 100 times it will be 100 times the same, it will be different if the page is included elsewhere). You need to let go of the idea that you control everything (that’s also the idea behind a mashup). You can get the rendered ID with some serverside JavaScript sprikled into your client code (document.getElementById(“#{id:elementID}”)), but that’s not what you want. You actually want to use a class rather than an ID. YOUR component might use the CSS only one, but the mashup that is running your component at some time might use it more than once, so a class is appropriate.
A bit confusing at first, but once you get the hang of it becomes clear.
Hth
jake said
agree w/Stephan. Use styleClass properties (gets rendered to style) for CSS and ID’s for programmatic manipulation.
Edwin said
Using styleClass works fine.