> > I'm working with a couple of the OSGi gurus on this issue. They're in town > for EclipseCon this week and I'll be meeting with them on Thursday. Don't > worry about doing anything... we'll get OSGi support into Lift. >
David and everyone, Thanks for all of your help on this and your effort on this Framework. I may be rambling and this may not be useful, but it helps me to clarify my thoughts to try to get them written down. I work for a school district with one other web/java developer and we are in a vacuum most of the time. So I do a lot of reading, trying to learn new things, but a lot of the time my understanding is faulty and so I am hoping some of you can point out where I have come to the wrong conclusions or where I am right for that matter. Your OSGi Gurus will most likely have much better insight, but here are my thoughts on Lift with OSGi and I hope to hear more after your meeting on thursday, will you be posting their thoughts on how this integration could/should occur. Here are some of my thoughts: Bundle Activation: * Initialize the lift framework and perform the boot actions (register bundle resource paths and snippet packages) * Export a service that could be called to process the lift request -or- register a servlet to handle lift requests * Register a service that can expose Lift templates to other bundles * Register a service that can serve the bundle's internal classpath resources Bundle Shutdown: * Unregister the services / servlet * Destroy the lift instance In a way the initialization process performed by the Boot class and the ServletFilter would be performed by the OSGi Bundle Activator Calling a Lift Service: There are two ways that I can see Lift utilized: 1) by registering individual servlets with OSGi, and 2) by having a service call a utility class that knows how to render the requested lift snippet/template. This utility class should be independent of the request mechanism so that it could be utilized by the current implementation, OSGi services and the portlet implementation. Template Resolution: There are two methods I can see for OSGi to work with Lift: Bundles export almost everything or bundles register template and snippet services. I believe that if the bundles export almost everything that the templating system should work, but there will be a great deal of direct dependencies between modules. If there was a service that each bundle could register its templates / snippets with these dependencies could be reduced, but this may require OSGi specific surrounds / embed tags. This would require embedded templates to be looked up in a service and when retrieved have its contents returned with all of the lift tags fully expanded. Likewise if a template uses a surround tag then the contents of the surround tag would be fully expanded and then the template service would be provided with the template name, content region and replacement xhtml content. What this would do is remove a lot of the direct ties to other bundles. For example, if an application contains three bundles: 1) The Core Module provides the template giving the overall appearance of the entire site 2) The Application template populates the core template's content region. 3) The Module template populates the Application template's moduleContent region. The Module Bundle (3) should not need to know that there is a Dependency on the Core Bundle's (1) template. As it only cares about the Application it is providing content to. This system would mean that all of the snippets used in a given template would have to reside in the same bundle as the template or be part of the Lift distribution to which all Lift bundles would have a dependency on. Resource Resolution: This is another point that would need to be addressed. If the bundles register the paths for their resources with a resource server service then it could facilitate looking up the resources in the registered bundles. Also, I can see having a utility class that could be configured in an activator and called by other services in order to retrieve resources. However, the LiftRules.resourceServerPath may need to be changed so that it can take wildcards so that prefix path elements could be ignored. For example, if the LiftRules.resourceServerPath is set to "*/classpath" then the following: <script src="/profile/private/blog/classpath/yui/event.js" type="text/javascript"/> would cause the bundles resource server to return the /yui/event.js file from the bundle. This is most likely very short sighted due to my lack of knowledge at this point, ... but hopefully not too far off base. -- Chad --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
