Forum OpenACS Q&A: Re: using an xowiki object outside of xowiki

Collapse
Posted by Stefan Sobernig on
Matthew,

If the object is created inside the other package, will this still work?

It would help a lot if you could outline your overall picture (task to achieve) you have in mind, i.e. the design context. I find it extremely hard to respond to your questions without having that because possible answers are too manifold, just to give you some examples:

  1. It seems to me that you want to use XOWiki or infrastructure, but not xowiki as end-user application? Am I right in this? In that case, I'd say you derive your own package from xowiki. There are a couple of examples around how to achieve this, e.g. http://cvs.openacs.org/cvs/openacs-4/packages/s5/ or http://icamp.svn.sourceforge.net/viewvc/icamp/ilogue/
  2. I could further assume that you want to integrate content managed in an XOWiki instance running aside into your package. Well, in that case you have at least two options, roughly speaking: (a) Integration through adp templating as shown by Gustaf Neumann above or (b) through the (programmatic) XOWiki content model layer.

In the latter case, I might ask myself why adp integration is insufficient. Or, to put it different, why you (plan to) use XOWiki infrastructure elements outside of an xowiki-derived package (i.e. at the programmatic level)?

Illuminate me!

//stefan

Collapse
Posted by Matthew Smith on
Stephan,

First of all, thank you for taking the time to ask such insightful questions. So far I have been impressed with the help I have received from here.

I know my questions are difficult, and I think that is becuase I don't entirely understand myself exactly how this is all going to work together. This project is for a new job with a new manager, and it is from him that these task requirements are coming. As time goes on I am understanding more and more, but I don't have the full picture yet, so I am having trouble asking the questions that need to be asked. At the same time I am trying to learn a new language which hasn't been easy because my background is in a procedural language(ColdFusion) and not an OO one. I appreciate the patience you and Gustaf have shown.

This is my understanding so far: We want to leverage some of the built in functionality provided by xowiki for the project. Namely, the documentation and permission features it provides. We are developing a suite of web services. For their adoption to be a success, we feel that the documentation provided must be excellent. We are hoping to somehow automate the documentation process so that non-programmers can come up with their own services, however at this point I feel that is a lofty goal and certainly won't be realized in the first iteration. Perhaps someday, but not now. However, I think we can use some of the tools like the permissions system and the documentation abilities provided by xowiki in this first version.

You mentioned two options:
(a) Integration through adp templating as shown by Gustaf Neumann above or (b) through the (programmatic) XOWiki content model layer.

I can't say which one is right for us to use. Really it comes down to which has the best documentation and examples out there and which will be the easiest for me to pick up.

Really I need a better way to develop and learn this stuff. I am trying to learn the api browser, but even when I do find what I am looking for it often feels like a lot of information I need is left out.

For instance, here is just one line of code that Gustaf kindly provided:
::xo::cc set_parameter master 0

I could not find ::xo::cc in the api browser. Gustaf was kind enough to explain a bit about it in another message. But I still have questions about all the other code in what he wrote. For instance, in the above code, what other parameters can be set? What do they do? And this is just one command. Where can I look up what I need to know and be self sufficient? I'm just concerned about being dependent on others to answer questions in a forum. It seems the information that I need is out there, I just haven't found out how to access it properly or look in the right place.

All that is a little of subject, but it's where I am at now. I'm a little concerned about the progress I am making and hope that I can improve how I am going about it.

Thank you.

Collapse
Posted by Stefan Sobernig on
Matthew


As time goes on I am understanding more and more, but I don't have the full picture yet, so I am having trouble asking the questions that need to be asked. At the same time I am trying to learn a new language which hasn't been easy because my background is in a procedural language(ColdFusion) and not an OO one. I appreciate the patience you and Gustaf have shown.

No doubt, it is hard to do all at once: learning Tcl, learning OO, learning the XOTcl OO-flavour, learning OpenACS internals, learning XOWiki internals etc. "Bon merde", as the French would say 😊


However, I think we can use some of the tools like the permissions system and the documentation abilities provided by xowiki in this first version.

Well, the permission system per-se is not an xowiki-specific feature. OpenACS itself offers this as infrastructure service to application packages as xowiki (based on a DB-backed "object system"). XOWiki adds some interesting and powerful features on-top, i.e. what I would refer to "access policies", roughly speaking.

By "documentation facilities", I assume, you refer to xowiki as authoring facility. So, you want end-user written documentation on your "web services" to be easy to contribute, with the help of xowiki, and make it visible a long with the expert documentation you deliver? And that's what your "integration" aims at, integrating xowiki-based end-user doc into the non-xowiki based expert doc? Well, in that case, I'd say option (a), adp-based integration, is a fairly good start.


I could not find ::xo::cc in the api browser.

::xo::cc is a helper object used in XOTcl-based OpenACS development that captures the current connection context, I guess in ColdFusion it is called "request" or something the like. It offers you access to the request information, permission checks for the current scope etc.

The reason why you couldn't find it in the API browser is because XOTcl due to its nature as object system is not natively integrated in the OpenACS API Browser, but it offers a different stage: Point your browser to /xotcl, e.g. http://localhost:8000/xotcl/show-object?show%5fmethods=1&show%5fsource=0&object=%3a%3axo%3a%3aConnectionContext. The XOTcl "Object system browser" offers very nice features, including source inspection, object relationship visualisations, object records etc. Bear in mind that XOTcl or xotcl-core is not (yet) part of the OpenACS Core therefore it is not always integrated seamlessly.


I'm just concerned about being dependent on others to answer questions in a forum. It seems the information that I need is out there, I just haven't found out how to access it properly or look in the right place.

Well, OpenACS API browser and XOTcl Object system browser are certainly a good start. Those more proficient in Tcl or XOTcl have their own strategies of simply reading the code. While there is (a little oldish) framework documentation on OpenACS in general, there is not yet sufficient for XOWiki or xotcl-core (while there is usage documentation). We improve the situation peu à peu, but this is simply a matter of (working) time and priorities. You might also want to check out the xotcl/xowiki-related sections at http://cognovis.de/developer/en/xowiki. A personal note from my side. A good way to handle this all-in-one situation you are facing is always to read others code and experiment with it (in a trial and error manner, indeed). So, look at the xowiki-based packages cited above (code is accessible) and try to link the hints we gave in our Guatemala xowiki tutorial on how to extend xowiki as framework to these code samples, see http://alice.wu-wien.ac.at:8000/s5-xowiki-tutorial/slides

Collapse
Posted by Matthew Smith on
Thank you Stefan. The resources you provided will be of help. I feel a little better now.