Portal 2.2 - virtual portal / theme / layout / context root

[pmn92]

I am deploying two virtual portals A and B.Both are using the same portlet P (deployed in A)

Scope

When deploying a page, window and instance of P in portal B I can refer to the portlet P using the scope "A" in the <compoent-ref> tag, correct?

Theme

I am deploying ThemeA with A and ThemeB with B, each linking to a CSS file. Using the portal management interface, I can change the theme of a page of B using the themeA defined in A. Correct?

Thus theme names are global. correct?

Now, if the corresponding CSS file defines a background image as url(/images/clown.gif") where should be the images directory? Do I need to define a context root for A and another for B and use url(/<context-root of A>/images/clown.gif") instead?

Layout

Same question with name and uri tags in layout.

Are names local, global or have scope ?

Thanks for your time

[mholzner]

"PMO" wrote:

I am deploying two virtual portals A and B.Both are using the same portlet P (deployed in A)

Scope

When deploying a page, window and instance of P in portal B I can refer to the portlet P using the scope "A" in the <compoent-ref> tag, correct?

correct

"PMO" wrote:

Theme

I am deploying ThemeA with A and ThemeB with B, each linking to a CSS file. Using the portal management interface, I can change the theme of a page of B using the themeA defined in A. Correct?

Thus theme names are global. correct?

correct. Theme names are defined by context + theme name, but you can use the theme name alone as a short hand, as long as the name is unique across all contexts. If you have two contexts containing the same theme name, you'll have to provide the context name as well to distinguish.

"PMO" wrote:

Now, if the corresponding CSS file defines a background image as url(/images/clown.gif") where should be the images directory? Do I need to define a context root for A and another for B and use url(/<context-root of A>/images/clown.gif") instead?

You shouldn't have to do anything about the context. the theme will take care of that automagically. Theme references are all relative to the context in which the css resides.

"PMO" wrote:

Layout

Same question with name and uri tags in layout.

same as in themes. Everything is interpreted relative to the context that hosts the layout.

[pmn92]

Thanks for the answers, seems perfect.

What do you call a context? Is it the <app-name> in jboss-app.xml ? the <context-root> in web.xml ? anything else ?

[mholzner]

to be perfectly honest , I get those confused all the time.

What I do is look at the available themes after I deployed them in the theme selector portlet. the "appID" that shows up there is what you want.

(and for the record: I think it's the context root, or the war file name (minus the .war) if none is provided). Anybody correct me if I'm wrong, please ;)

[pmn92]

Thank you.

Portal 2.2 is a major release compare to 2.0 - although it claims to be minor. Deployment package is really a great feature: it allows me to release separately core sw package, virtual portal and client package(theme+layout), facilitating a deployement policy for maintainance release of each.

I had really difficulties to deploy my application the first time - first I got crazy because of the if-exists "keep" attribute that I copied from the example (errors became persistent) and second I mispelled the "-object.xml" file by adding an "s" to object. I wasted hours. I suggest more traces in parsing all these descriptors.

Thanks again.

[antoine_h]

I agree with PMO.
sometime get crazy with the description that is in the DB, and the one the descriptor.

may be open a JIRA ?
I don't use yet 2.6.
So I don't know how the descripting files are managed in 2.6
no use to open a JIRA if it is better.
anybody knows things about that in 2.6 ?

Thanks

[theute]

About ?

We can't tell if someone is spelling foo-object.xml wrong. The only thing we can do is to validate when there is one. (i think there is a Jira about it, but i am not sure)

[antoine_h]

I suggest more traces in parsing all these descriptors.

not mispelling error, but some log ?

logs telling :
pageA is "keep" : definition is from the database
pageA has (from database) : windowA, WindowB, etc...
pageB is "keep" : definition is not in the database => set it.
pageB has windowC, WindowD, etc...
pageC is "update" : definition is replaced in the database
pageC has (from xml descriptor) : windowA, WindowD, etc...
etc...

with some easy way to set the log on or off (with levels ?).

and the same for instance...

something to know what is actually in use.
because the two sources of page/window/instances description are sometime hard to follow and be sure of what is in use.

[antoine_h]

by the way : usually, when working on page/window/instance description, and things seem not to work "as I think it should be" :
- I stop the server (dev)
- delete all rows in the object tables in the database
- and restart the server.

most of the time, things appear more clear why a window is not there... or the "real new window" (with proper instance/portlet) appear...

I use this sql script to erase the portal objects database :

Delete From JBP_INSTANCE_SECURITY_ACTIONS;
Delete From JBP_INSTANCE_SECURITY;
Delete From JBP_INSTANCE_PER_USER;
Delete From JBP_INSTANCE;

Delete From JBP_PORTAL_MODE;
Delete From JBP_PORTAL_WINDOW_STATE;
Delete From JBP_CONTEXT;
Delete From JBP_WINDOW;
Delete From JBP_PAGE;
Delete From JBP_PORTAL;
Delete From JBP_PORTAL_OBJECT_PROPS;
Delete From JBP_PORTAL_OBJECT;

Delete From JBP_OBJECT_NODE_SEC_ACTIONS;
Delete From JBP_OBJECT_NODE_SEC;

Delete From JBP_OBJECT_NODE order by PK desc;
Delete From JBP_PORTLET_STATE_ENTRY_VALUE;
Delete From JBP_PORTLET_STATE_ENTRY;
Delete From JBP_PORTLET_STATE

All table are kept, only rows are deleted.
Order of lines is important and one delete at the last part is "order desc", to avoid some referential integrity error.