[Design the new POJO MicroContainer] - Re: AbstractController add/removeControllerContext
by alesj
"alesj" wrote :
| e.g. ScopedKernelController extends AbstractKernelController extends ScopedController extends AbstractController
|
If I do this it works and nothing is public.
ScopingKernelController has package protected methods:
| void addControllerContext(KernelControllerContext context)
| {
| super.addControllerContext(context);
| }
|
| void removeControllerContext(KernelControllerContext context)
| {
| super.removeControllerContext(context);
| }
|
| void release()
| {
| getParentController().removeController(this);
| setUnderlyingController(null);
| setParentController(null);
| parentKernel = null;
| }
|
since it is only accessed in PreInstallAction, which is in the same package.
The only change to AbstractKernelController is that it extends ScopedController instead of AbstractController.
This is how ScopedController looks like:
| /**
| * Scoped controller.
| *
| * @author <a href="ales.justin(a)jboss.com">Ales Justin</a>
| */
| public abstract class ScopedController extends AbstractController
| {
| private AbstractController underlyingController;
|
| public void setUnderlyingController(AbstractController underlyingController)
| {
| this.underlyingController = underlyingController;
| }
|
| protected boolean isScoped()
| {
| return underlyingController != null;
| }
|
| protected void addControllerContext(ControllerContext context)
| {
| if (isScoped())
| {
| underlyingController.removeControllerContext(context);
| context.setController(this);
| registerControllerContext(context);
| }
| else
| super.addControllerContext(context);
| }
|
| protected void removeControllerContext(ControllerContext context)
| {
| if (isScoped())
| {
| unregisterControllerContext(context);
| context.setController(underlyingController);
| underlyingController.addControllerContext(context);
| }
| else
| super.removeControllerContext(context);
| }
|
| }
|
It has protected methods, so that they can be accessed in ScopedKernelController.
And AbstractController now has package protected methods:
| void addControllerContext(ControllerContext context)
| {
| registerControllerContext(context);
| }
|
| // TODO This api looks broken and unsafe see above
| void removeControllerContext(ControllerContext context)
| {
| unregisterControllerContext(context);
| }
|
Is this OK?
Or too ugly hack?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4072958#4072958
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4072958
18 years, 8 months
[Design of JBoss Portal] - Re: portletbridge/web-clipping
by chris.laprun@jboss.com
"cdelashmutt" wrote : After trying out the latest portletbridge (circa Jan 2007), I'm beginning to question the value of a full page in a portlet window. It seems to me that it might be more useful to simply clip a small part of a page. For instance, there is perhaps this table that you want to display, but you really don't need anything else.
I agree that the full page clipping is not that useful as well for the general case. However, I see web clipping as being used mostly to integrate existing web apps into a portal environment. In this situation, retrieving the whole page would make sense.
"cdelashmutt" wrote : Web Clipping in general has many challenges. Does it make sense to include CSS styling from the source? What about JavaScript? Personally, I'd rather the source strictly be used for data, and the portal styles should be applied to the content.
It's difficult to tell in a generic way. This could potentially be done if the imported markup was semantically written but this is far from being the norm (e.g. how many times do you see tables used for laying out elements?). Also, even with semantic markup, it could be quite tricky to discard CSS styles as they could be used for things as progressive disclosure of elements in conjunction with javascript, hence leaving you with more content that you really should be rendering.
"cdelashmutt" wrote : Specific to portletbridge, I tried to point it to Slashdot, which is what they seem to use for testing. In Portal 2.6, this causes the Renaissance theme to get corrupted. I don't know if this is a Portal problem or what, but it seems like the slashdot styles are leaking into Portal. The image and link HREF stuff does seem to be re-written properly, it's just that styling that is messed up.
|
| Strangely, portletbridge actually only seems to work properly with plan HTML. If I try to go to a site that claims to be XHTML, I start getting problems. For instance, I've tried to clip some stuff from a site running RT, and none of the link re-writing works.
|
| Is there any interest in this type of a feature? I thought I was interested, but I don't know if it even makes sense now.
I think there is a huge interest but as you pointed out, there are also lots of problems. I am investigating things to see what can be done to improve the situation.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4072949#4072949
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4072949
18 years, 8 months
[Design the new POJO MicroContainer] - AbstractController add/removeControllerContext
by alesj
"adrian(a)jboss.org" wrote :
| I note you've still not fixed some of the public methods you introduced
| on the AbstractKernelController that I complained about before.
|
| They need fixing otherwise somebody can break the entire state machine with injudicious
| (or malign) invocations on those methods.
|
| This is basic OO principles. All public methods should keep the invariant state
| of the underlying Object, there should be no backdoors. :-)
|
Actually it's not AbstractKernelController, it's AbstractController, which complicates things - different package then ScopedKernelController - otherwise I could use package protected. :-(
Looking at the code, I don't see how else I can move context from underlying controller into scoped one.
Except for changing the whole impl, putting the scope information into base controller concept - which doesn't look that trivial to do. :-)
Any ideas how to keep the current impl and at the same time remove this ugly public backdoors?
e.g. ScopedKernelController extends AbstractKernelController extends ScopedController extends AbstractController
And make those methods package protected?
Too ugly and outside concept?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4072939#4072939
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4072939
18 years, 8 months