311
jegelstaff
Re: PHP Surveyor Ported to Xoops

I will definitely be checking this out. Surveys are a special breed of data entry form, and it can never hurt to have a dedicated solution for that need, even if "ad hoc" forms are handled elsewhere (our Formulize module, soon to be released).

I particularly like the sound of accomodating data entry from paper based surveys, and the flexibile templating system, both big requirements for large survey projects we've done before.

--Julian



312
jegelstaff
Allow YYYY-mm-dd to be a default for date select boxes

Currently, if a module calls the xoopsform class and creates a date select box, and passes a non-date value as the initial value of the box, then the current date gets put in the box.

This makes it impossible to create a date select box that is blank, or has no date in it initially.

Not being able to initialize the date select box with a non-date value means that when the form submission is received, unless the user has specifically cleared a box and made it blank, the current date will be received (since the current date is the current default value).

The problem with that is that the module writer has no way of knowing if the current date is what the user actually picked, or if the user just ignored or neglected to fill in the date select box.

This change solves that problem by allowing the date select box to be initialized with a non-date value (ie: "" is recommended), and that results in YYYY-mm-dd being written into the box as the default value. The popup calendar defaults to the current date in this situation, but the box itself does not contain the current date unless the user specifically selects the current date in the calendar (or types it in).

It's a pretty simple patch, just a few lines changed in two files. You can get it and read more here:

http://sourceforge.net/tracker/?func=detail&aid=1077123&group_id=41586&atid=430842

The link is at the bottom of the page.

Of course, we would like to see this integrated with XOOPS 2.0.9 or later. It doesn't adversely affect existing modules, and allows module writers more accuracy in handling dates using the xoopsform class.

--Julian



313
jegelstaff
Re: Registration Form editing!

There are several threads with information about this. The best one I know of is here:

https://xoops.org/modules/newbb/viewtopic.php?topic_id=20250&forum=27

Post number 3 has a lot of info.

Good luck,

--Julian



314
jegelstaff
Re: Recommendation for a module please:
  • 2004/11/25 18:50

  • jegelstaff

  • Module Developer

  • Posts: 518

  • Since: 2004/7/2 2


If you want straight HTML on the screen, and aren't concerned about article management, we recommend WF-Channel. We have a perl script for cloning it so that you can create infinite individual sections on your site. More details here:

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

Good luck,

--Julian



315
jegelstaff
Re: permissions
  • 2004/11/24 17:14

  • jegelstaff

  • Module Developer

  • Posts: 518

  • Since: 2004/7/2 2


Is there a date after which no one is allowed to vote in the poll? Sounds like a config issue within the module to me, not a XOOPS core issue. Good luck,

--Julian



316
jegelstaff
Re: Flexible Forms - STORED IN DB WITH REPORTING
  • 2004/11/19 18:27

  • jegelstaff

  • Module Developer

  • Posts: 518

  • Since: 2004/7/2 2


This was the big missing link for us when we started with XOOPS. It could do just about everything we needed, expect this. So we built a module to do this (on top of Fomulaire).

It has a lot of the features listed here, plus has a reporting system built in which you can use to publish reports to groups of users.

It's a really big, huge, and somewhat ugly (code-wise) hack of Formulaire.

It's true that there are more powerful data analysis tools out there than we could ever build in PHP/XOOPS, but the convenience of being able to do rudimentary reporting inside XOOPS, and to be able to use XOOPS as a report publishing platform to groups of users in your organization, is very significant. For the right audience, ie: a non-technical one that doesn't have access or familiarity with data analysis tools, built in reporting features can be a real godsend. And the ability to push data to users through publishing reports inside XOOPS adds a lot of value to the XOOPS platform within an organization, if you're trying to make a one-stop portal for all business transactions.

Some of the more advanced features in our module....

--Form creation interface the same as Formulaire

--Forms can be single submission or multiple submission, enforced through DB flags, though the assumption is that only registered users are filling in forms. Anonymous users can fill in forms too, but don't have access to some of the more advanced features.

--Registered users returning to a single submission form get their one entry displayed for editing. Multiple submission entries can be edited by selecting them from the "View Entries" page.

--Viewing of entries can either be limited to your own entries only, or all entries by other users in the same groups as you (a per form, not per user, setting)

--Full reporting features:
* search with =, LIKE, NOT, NOT LIKE, <, <=, >, >= operators
* AND/OR search options, both within a field and between fields
* calculations: sum, average, count, min, max, percentage breakdown
* sorting by any field
* "scope" control over the report results, so admins can generate reports based on data from entries in multiple groups, not just their own groups
* Report publishing controls so users can view information that admins want them to be able to see easily (users can make their own private, unpublished reports too).

--Full admin interface, so users can be admins over specific forms, without having admin access to the entire Forms module.

--"Proxy" entry system so admins can submit data on behalf of others, and can edit other people's entries if necessary. This allows for situations like where someone faxes in a paper copy of a form to the office and someone in the office needs to enter that data into the system, but have the data flagged as if it were entered by the person who faxed the paper copy in the first place.

--Capability to link/join forms, so entries in a field in one form become the list of options in a selectbox in another form. This is one of my favs.

--Notifications so you can get a message when someone fills in a form. Also very cool.

Unfortunately, it's pretty much complete spaghetti code right now, thanks to the way it was built incrementally, and way too fast, starting as a simple hack of Formulaire. But it works pretty well I would say. We have not released it yet, and for various business planning reasons, hadn't planned to do so until it was in a more polished and professional state.

But of course, help from the XOOPS open-source community could help it get there faster, though in truth, it's such a complicated module that significant contributions to deal with some of the underlying architectural issues on the to do list would be very difficult for anyone but us to do; that's just to say that I'm not sure that releasing would in fact help get the module to a more professional state faster, but it would of course enrich the community.

One of the biggest issues for users right now is that the reporting system is really slow once you have a few hundred entries in a form (still quite usable, but noticably slow).

There are also structural issues with how the data is stored arising from the way the module was built on top of other modules, so to properly add in new features and improvements, some of those deep issues need to be addressed.

The interface is also a little clunky. Functional, but not polished. And you get into a lot of horizontal scrolling when you start viewing lots of fields in a form, which can be rather annoying.

Anyway, you can view a demo of the module if you go to:

http://demo.freeformsolutions.ca

The "Activity Log" in the "Form Menu" is the one demo form available there. That will give you a basic idea of what the module does. There is no demo of the backend admin side.

I would of course be happy to get feedback on this. Desperate pleas for a release will be considered.

--Julian



317
jegelstaff
Re: Registration Codes
  • 2004/11/16 15:10

  • jegelstaff

  • Module Developer

  • Posts: 518

  • Since: 2004/7/2 2


That would be several hours of work and can't be easily explained in a forum posting. You will need to put your PHP, mySQL and XOOPS hacking skills to work; you would need to modify the file that contains the registration form, plus the logic that reads the form, plus the module code to provide a way for the admin to specify the list of groups (unless you want to hard code the group list), plus the interface for the admin to do that....

Also...we will be updating this module for 2.0.9 soon.

--Julian



318
jegelstaff
Re: Porting exciting Flash Chat module for Xoops
  • 2004/10/30 23:40

  • jegelstaff

  • Module Developer

  • Posts: 518

  • Since: 2004/7/2 2


For $5, you can get a copy of FlashChat, an existing and very nice Flash based chat application that is already ready for installation in XOOPS (and a ton of other CMS/Portal systems).

Here's the link:

http://tufat.com/script.php?id_num=2

No, I'm not affiliated with the programmer. I'm just a happy customer. Considering how nicely it integrates with XOOPS, and how cheap it is, and how pretty full featured it is, it's hard to see why one would work on another module.

Good luck,

--Julian



319
jegelstaff
Re: Working with Permissions and Groups
  • 2004/10/30 23:36

  • jegelstaff

  • Module Developer

  • Posts: 518

  • Since: 2004/7/2 2


Quote:

1)The problem is that there doesn't seem to be one general way to do this. Each module kind of has its own system.


Yup, this is the general wall you'll be running up against when trying to do what you're doing.

XOOPS has no built in workflow control. Each module is literally its own system in this regard.

Quote:

2) And for some reason I have not received any automatic e-mails telling me that there was been a content submission to the site.


Your ability to receive e-mails is completely dependant on the notifications options of the modules you're working with. If the module does not support providing notifications for the particular event you're interested in getting a notification about, you're stuck.

This goes back to the first issue; modules are their own little worlds.

Quote:

3) Can the "editors" view and make corrections to the postings without having to enter the admin back-end of the site?


Again, totally depends on the module, but in most cases I would guess the answer is no.

Someone with more experience with the modules you're using can perhaps answer with more details about how to do some of these things with them.

Good luck,

--Julian



320
jegelstaff
Re: HACK of liaise contact module
  • 2004/10/28 14:10

  • jegelstaff

  • Module Developer

  • Posts: 518

  • Since: 2004/7/2 2


I believe the module Formulaire does this, or something similar.

--Julian




TopTop
« 1 ... 29 30 31 (32) 33 34 35 ... 38 »



Login

Who's Online

151 user(s) are online (103 user(s) are browsing Support Forums)


Members: 0


Guests: 151


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Apr 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits