I've not made a concerted effort to try and do what you're doing, but some observations that might help...

Your idea to look at it in reverse is a good one, but also highlights the fundamental challenge.

XOOPS handles all rendering of information to the screen using its core libraries. Every module, and everything in the core of XOOPS, is all setup so that once the logic has finished doing its thing, all the details are sent to a page rendering function of one kind or other that spits out a formatted HTML page for the web browser.

What you want to do is decouple the rendering of that information from the rendering engine itself. If the information were rendered separately from the XOOPS core and then handed off to XOOPS, that would make it easier. But that's not the way it works.

However, if you look at the main template file for the default theme, you'll see that by the time -- very late in the rendering process -- that the master page gets drawn, the center block contents are contained inside one single smarty variable. You could rewrite the entire template for the theme your XOOPS site is using and simply display that single smarty variable in a different way.

I think, though, that you are more interested in displaying the output of a module on another site, rather than simply displaying the output of a module without the XOOPS theme surrounding it? Unless the module author has created a way to export the information in the module for use on a non-XOOPS page, you'll have a very hard time doing the former. But simply stripping away the XOOPS theme, that's fairly simple if you modify the template.

But if you completely cut back the template, then you'll have no navigation controls that will let you get from one module to another.

If you setup your site in frames, and had navigation links in one frame that changed the contents of another frame, then you could make all those links call up a different stripped-XOOPS page in the other frame, that might work.

If you strip back the theme though, you'd have a hell of a time working with your XOOPS site to get information into it, since there would be no navigation elements, login boxes, etc, in your XOOPS site any longer.

Perhaps there's a way to pass a variable in the URL that will specify a template to use, so you could strip down the default template, and then for purposes of actually logging in and working with the XOOPS site, you could use a slightly different URL, ie: www.myxoopssite.com/?template=admintemp

You'd have to ask someone else if there is such a template hack out there. If there is, it would probably make more sense to use the URL passed template as the stripped down one, so your XOOPS site works like normal by default, but inside your frame site, the XOOPS content is displayed without the basic template.

Confused yet?

--Julian

For details about the how's and why's and wherefor's of this, check out this FAQ topic:

https://xoops.org/modules/smartfaq/faq.php?faqid=9

There's a detailed comment (copied from another useful forum post).

--Julian

Quote:

That depends on your FTP software (and your server's settings too). Filezilla (http://filezilla.sourceforge.net/) normally lets you change perms on files/folders.

--Julian

Quote:

What I'm saying is that if you do a two stage process like what I described, then your end users will complain. It's not a matter of how flexible or not the approach is for the admins, it is simply a fact that when users register, they want to submit all their "profile" style information and be done with it. They get very confused when you have to create an account and then fill in another profile form after logging in, especially when the system does not force them to fill in the form (it does not pop up on the screen and refuse to go away until they've filled it in, for instance). The combination of a confusing process, plus no technical enforcement systems, leads to the need to bug users repeatedly to complete the second form inside the system.

Hence our interest in expanding the account creation process.

The biggest stumbling block in my head right now is trying to figure out exactly how to do report generation on the data in the profile. We like having the second registration form provided through Formulize, because we can then generate reports and stats on the info. It's very hard (impossible?) to think of good ways to build an extension to the core that can also be read by the report system in Formulize; the format of data in Formulize is completely different from the format of data in the current user profile system. This might mean that the approach we settle on is ultimately a big hack, rather than true integration to the core.

We have a very long to do list right now, and the changes to the account creation process are not at the top of the list unfortunately. However if there is any chance of integrating them with 2.2, we will need to at least put together a spec sometime soon. So I hope to put out a spec by the end of the month perhaps, but honestly, it's really hard to know when it will happen, and depending on the schedule for 2.2, this might be an improvement that goes into the first release after 2.2, not sure.

And just to be clear, we're not part of the core dev team, we just submit suggestions and patches and such like anyone else.

--Julian

Bump!

I was just wondering if a core developer has had a chance to look into these small changes. They really are very simple, but add some very useful functionality to the date select box. I think they could be added to the core tree without affecting anything else. I notice there has been no response on Sourceforge either.

--Julian

I believe XOOPS supports authentication against an LDAP database. If Coppermine does too, then you could go that route and have one LDAP database that both systems used for authentication.

There is a port of Coppermine to XOOPS called xcGallery. That would let you essentially put Coppermine as a module inside XOOPS, though I don't know if an "upgrade" is possible, ie: you might not be able to move your existing Coppermine content into the XOOPS module.

Good luck,

--Julian

Quote:

Formulize, our ad hoc form creation and reporting module, does that, sort of.

We currently have created registration forms that are separate from the account profile forms. The account profile forms are integrated with the XOOPS core, so they are hard to modify. Instead, we have opted for a "two-step" registration process. First people create their accounts as usual. Second, they need to fill in the separate Registration form we have created to provide all the other data that needs to get tracked which isn't in the account profile.

Most users do not like this though, and to some it is extremely confusing to have this two stage process.

What we are planning on doing is creating a flexible account profile system so that you can define what fields you want in the profile, what fields show up as part of the account creation process, and also what fields are unique to which groups. We feel it is important to be able to have different account profile fields for a Researchers group as opposed to a Volunteers group.

Integrating all that with the existing account profile and registration system is not trivial. But it is something we are working on, and we will be releasing a specification for how we see such a thing working in the near future, though not sure when. I would like to see such work integrated with XOOPS 2.2.

Quote:

Formulize does this.

Quote:
[/quote]

The intended use of Formulize is only by registered users, but if you want to setup a XOOPS site so that anonymous users have access to forms, that works too.

Partial demo at:

http://demo.freeformsolutions.ca

It's all the stuff under Form Menu.

--Julian

Cool! Sounds like great improvements, I'll check it out.

--Julian

Hi there,

Calendar modules...there's a few to choose from but in our investigations, we didn't find any that had the kind of fine-grained group permission structure that you're looking for here. So unfortunately, I think you're stuck with the global permission level. This is a recurring problem we run into when trying to find modules that are suited for use in a business context.

We would really like to port WebCalendar to XOOPS, and include a detailed group permission structure. I think that would kick butt. WebCalendar is a standalone calendar app, that you can read about here:

http://www.k5n.us/webcalendar.php

--Julian

Quote:

Maybe over the holidays, but probably shortly after in January. And I should mention that it is not in Beta. It is currently in use in a production environment with over 1000 users.

Draven just started a thread about PHPSurveyor here:

https://xoops.org/modules/newbb/viewtopic.php?topic_id=28093

And for anyone interested, I posted some info about Formulize in another thread here, on page 2 (this thread has some info about Mith's module too):

https://xoops.org/modules/newbb/viewtopic.php?topic_id=26987

In a nutshell, Formulize is an ad hoc form creation and reporting tool. It's based on Formulaire.

You can use its graphical interface to create any kind of data entry form you care to have, Status Report, Registration Form, Activity Log, Task List, Inventory Tracker, any kind of situation where you're filling in a form to record data in a database.

The data is stored in the database, and can be reported on (searched and aggregated) using the integrated reporting tools. You can also save reports for your own reference, or publish reports to other users.

There is a detailed permission system that lets you control which groups of users have what level of access to which forms. There are also some "advanced" features that let administrators submit data on behalf of other users (manual entry), and let you link two forms together so the entries in one field in one form become the options in a field in another form. And it's tied into the XOOPS notification system too.

As I mentioned in that other thread though, it's a little rough around the edges. It's pretty much bug free (there's some minor stuff on the admin side that there are workarounds for), but under the hood the code is a bit messy, making refinements and improvements a challenge. We're doing a small bit of cleanup, and some documentation prior to release.

We have some far out plans for where it might go in the future. I would like to see some flexibility added to the front-end user interface, so you can pick what "screen" is the default for a particular form (either the "add an entry" screen or a specific report), and also the ability to define some reports and set them up as dedicated links in the navigation UI for that particular form, so you have fast access to the really useful views of the data.

For example, this would let you create a form such as a task list, define some "views" or reports on the data that has been entered, set one of those reports as the default view, and thereby essentially create a "task list module" for XOOPS, without any programming whatsoever.

There's a very basic demo available here:

http://demo.freeformsolutions.ca

There are two forms in the "Form Menu" when you login, and they show the two basic kinds of forms that are possible (there's a couple other variations too): multiple entry (Activity Log) and single entry (Conference Registration).

(JMass, the Conference Registration form is newly added to the demo.)

We're looking forward to working with the community on future versions of Formulize in the new year.

--Julian