Who would like to test Formulize 4 RC1?
Formulize 4 is nearing RC status. We're aiming for Monday.
It will be really important to do some testing on this release right away, so we can reach full release by later next week.
So anyone who is able to spend a bit of time installing it and double checking things, that would be greatly appreciated.
Especially important would be testing site upgrades. If you have a dev copy of a site you maintain, or you can make a backup copy, and install Formulize 4 there, that would be very excellent. Testing upgrades on sites with frameworks and custom code, that would be a sweet spot.
Thanks, we'll post updates to the forums as things progress.
--Julian
Comments
I'll try and get to it in the
I'll try and get to it in the next few days. We were using the SVN from awhile back on one site and it worked. I have a few pieces of custom code to integrate, too for sorting issues and the likes.
Good news - Version 4!
I noticed that Julian is cleaning up and ready for the next release. Great News. Since the release of the 3.x series I have been testing using the SVN and it has been working great up until that one from yesterday 7 June 2010.
I will continue test this week and get back as I go along. I haven't been able to post here more often since I had a new baby boy in my family, we know how that goes need time and attention. But here I am back things are normalizing again. I am willing to contribute testing time to see this project move ahead.
I Test, in Brazil.
Hi!
I like to test Formulize 4 RC1! Would be testing site upgrade.
Where's the download?
SQL error in Formulize 4 RC - class/elements.php
Julian - I started with a fresh install, just to make sure everything worked in that environment - and I had problems building a form from the old admin panel.
Traced it down to an extra parameter in a sprintf() call in class/elements.php. You can see the details here - http://community.impresscms.org/modules/newbb/viewtopic.php?post_id=3860...
Using ImpressCMS 1.2.1 and SVN from June 7. I see you've made a few other commits - I'll update my sandbox.
Steve
Christian Web Resources
New interface
Hi Julian,
Is there a new interface or will there be one for the release, I keep applying updates ever-since 3.x and see the same interface. Le me know.
Thanks one and all!
Hello,
Thank you for your interest! :-)
And congratulations to btsec!!
Thanks Steve for the bug fix...removing the first %u in that statement you found does indeed fix the issue...I removed some unnecessary stuff that was in that method recently as cleanup, but didn't remove the %u that was corresponding to the bit I removed. It's fixed now and committed to SVN.
What would be super for now would be people testing the upgrade procedure, and seeing if the site still works the same. Framework handles have been deprecated finally, and the code for that is in SVN. So if anyone is using frameworks in their site, and has saved views on the frameworks, or API code in their site that refers to framework handles, we need you to test the upgrade process itself, to see that it doesn't break anything in your site.
Existing framework handles should be OK to keep using, with a few exceptions that the upgrade process is supposed to highlight and explain to you. So that is a big issue to test out.
Gradually, we're adding more and more to the admin UI. You can access what is there for now by starting at this URL in your site:
www.yoursite.com/modules/formulize/admin/ui.php
That is still very much a work in progress though, we're still testing bits of it and adding others. The framework stuff is much more important to check out at the moment.
I'll post back here when there's a more complete version of the admin ui to check out.
Thanks!
--Julian
Will be testing upgrades to 4RC later
Julian - have you given consideration to the point I brought up in the ImpressCMS forums? I'm not sure about XOOPS, but ImpressCMS has been using jQuery and it is part of the core already and active for all sites at 1.2, or higher.
Steve K
Christian Web Resources
Yes, I would prefer to use the included copy with the core
Hi Steve,
Yes, I think we'll almost certainly adjust the final release to point to the included copy of jQuery. That totally makes sense....as long as it's the latest one. Because of a bug in 1.7.2 of jQuery UI, we require 1.8.2 of jQuery UI.
--Julian
Error in 3.12 to Version 4 SVN
Hi Julian!
Excuse me, Julian. Upgraded from 3.12 to Version 4 Xoops 2.4.4 in SVN now recommended, but this is what happened:
1. Do not appear in the administrative area of the module the list of existing forms. But in areas like the links module and permissions are available.
2. In the frameworks for this message: Error: data could not be written to the database entry is new in form x.
3. My language is Portuguese, words with accents like "administration" appear like this: Administration § Ã £ o.
4. You also can not create new forms. There are errors in creating these, and also in creating new fields.
This is my experiment.
Thank's!
Marcelo.
Hello, sounds like you need to apply the database patch40
Hello,
If you're upgrading from 3.12, then you need to apply "patch40" to the database. This is exactly like the "patch31" step described in the readme file, but just type patch40 instead. If you don't do that step, then pretty much nothing will work, just like you described.
We are nearly done getting the 4.0 release ready, and the SVN version is in a bit of flux. If you want to use the SVN version for real purposes, we recommend going to revision 383, and there's a link in the download page specifically to that revision. If you want to test the latest UI and newest stuff in version 4, from a testing point of view, then use the latest version in SVN.
As for the bad characters....that will be a character set issue. The text may not all be UTF-8. There's not much to do there except fix each of the reported instances. I don't believe there is a complete Portuguese translation anyway. I am happy to give commit access to anyone who wants to help update the files. Let me know.
--Julian
readme updated
Julian,
Perhaps you can create a read me file for the SVN now.
Good idea
I'll commit one right now.
--Julian
Planning to test
Hi Julian,
I am also planning to test. I have a website with multiple forms, custom code in rendered fields using multiple frameworks, pageworks pages and specialized pageworks functions in some special cases.
I just have not found the time yet.
Thank you.
Apache, MySql PHP Versions
Hi Guys,
Just letting you know I am using:
# Apache Web Server Version 2.2.8
# PHP Script Language Version 5.2.6
# MySQL Database Version 5.0.51b
and it works great so far with the SVN as from Monday 14 june and using the existing interface. (I will setup a separate installation to test the current svn as regular as I can). Only thing have noticed so far is that if you have implemented some criteria (whether to display or not if a condition is met based on another field) for some fields you have to revisit them, since I noticed their is a change and the fields may not be displaying as intended.
So the problem is with the conditions on displaying elements?
Thanks for the feedback. So you're saying that if you had an element where you said, "only display this element if the response to question X in the form is 'Yes' " then in that case, this condition would be missing and you would have to respecify?
Are you in the old UI or the new UI? In general, things are in pretty big flux on June 14. The "stable" version in SVN is revision 383 from June 10.
Currently, the new UI should work for almost everything, except editing elements. That's the big missing part right now. You can probably still edit elements in the old UI, although I'm not certain.
Testing the effect of the upgrade on frameworks is a big deal, since the framework handles are deprecated now.
I'll post back here once the SVN copy is feature-complete.
--Julian
Ui.php blanck page (402)
Hello Julian,
I upgraded to the recommended version of SVN by patch40. And everything worked.
Then upgraded to the latest revision available (402) to meet the new administrative interface. But ui.php page is blank. Then, via the administration of Xoops modules, updated the module. The page went blank.
Not figured out how to undo the operation _FORM_LOCK_TEXT.
Thanks!
Marcelo.
You probably just need to re-run patch40
Hello,
If you re-run the patch40 step, then I think it will work. Also, updating the module so the new templates kick in, is required. But you already did that.
Thanks for trying! Let us know how it goes. There will be a new revision in the SVN later today that will have be 99.9% complete.
--Julian
Problem Design
Hello,
I installed the latest SVN, I have seen great changes in the administration interface. Is a bit confusing at first because the proposed organization is quite different form the previous one. But this very good.
I put this address: http://www.cnbbsul4.org.br/dados/uploads/screen_formulize.gif an image problem in the distribution of elements on the page, including text overlay. This happens on Settings and Elements.
With respect to existing content, it was preserved.
Marcelo.
More
More:
Although, the form exists in http://www.cnbbsul4.org.br/dados/modules/formulize/index.php?sid=6 on Screen: Stories of Activities (ui.php? Screen page = & sid = 6) displays blank page. This happens with other forms.
Also this error: /* eval */ window.location = 'http://www.cnbbsul4.org.br/dados/modules/formulize/admin/ui.php?page=form&aid=0&fid=10';
And: Words with graphic signs: é, ç, ã, ó and more, Latin languages are corrupted forms of the title as in: Form: Avaliação what it Form: Avaliação.
Do not Create elements in a new form: Error: could not determine element id when saving display settings
Do not know if this is a problem, but in the administrative area of formulize is different and seems out of xoops administration.
Installed OK on XOOP 2.4.5 rc3
Just wanted to note that the latest as of june 25 Formulize SVN installed ok on xoops 2.4.5 rc3. May I suggest that there be some way for navigation i.e. moving to and from fields, to and from fields to forms or to formulize admin home page, or withing the different tabs, sort of indicating step 1, step2, step3, probably some button that indicate go to next step, finished, go to form, go to main admin page, add cancel or save button for the forms and fields. I had to use the breadcrumb/path link at the top to navigate from field to form or to formulize admin page.
Also about the advanced search button in the actions section, probably this needs to be updated/remove stuff that have been deprecated, since some end users might tend to use it or may not read the notes and thus get wrong output.
The look and feel is just great the community will or already likes it, that's for sure.
Thanks for the feedback
Marceloz, some of the issues you reported have been addressed, I think. A more final version was completed towards the end of the week in which you posted. Some of the others, I can't say for sure. I am surprised about the accented characters...the character sets didn't change or anything like that.
If you can try things out again and see if the same issues occur, I think we will need to go through them step by step.
Btsec, good point about the advanced search. We should make it show up only when the view has advanced search terms already. Users who have old saved views will need to interact with that UI. But otherwise it should be turned off now.
One of the ideas in the new UI is that the tabs are a sort of step by step progression...you make a form, you add elements, you adjust permissions...things are kept together for the most part. The breadcrumbs are supposed to be used for jumping around if you need to, but that's a good point that a more explicit "back to the form" or "back to home" link might be useful. We'll be doing some updates later this week or next week I think.
--Julian
About Formulize in Latin and Uft8
Hi Julian,
The problems of characters that talked in the previous message does not happen when XOOPS is for UTF-8. As is the case that I'm using now.
When installation is for Latin characters (ISO-889-1), it causes problems, including in the "Form name" to create it. But when I installed the standard UTF-8, nothing wrong happened.
Anyway, I sent for you to access an account with the problem so you can see it, if interesting. Or you can reproduce the problem on your site, installing a xoops using ISO-889-1. Even the last update Formulize, married problems with graphic signs.
The other problems were apparently solved.
Thanks!
Marcelo.
P.S.: The package xoops 2.4.5 + includes the translation files in UTF-8 *, (Recommended for new installations mainly because it is the standard adopted today by XOOPS) and ISO-889-1 (Maintained by compatibility for old sites that already use this coding) for both the core XOOPS, as for modules and themes.
Testing RC3, revision 442 - SQL schema differences
Julian, I've been doing some basic testing of F4 and the latest ImpressCMS trunk (mostly to test my changes to ICMS module administration), but in doing so, I have found some differences in the SQL schema defined in xoops_version.php and in sql/mysql.sql.
in xoops_version -
// Tables created by sql file (without prefix!)
$modversion['tables'][0] = "formulize";
$modversion['tables'][1] = "formulize_id";
$modversion['tables'][2] = "formulize_menu";
$modversion['tables'][3] = "formulize_reports";
$modversion['tables'][4] = "formulize_frameworks";
$modversion['tables'][5] = "formulize_framework_forms";
$modversion['tables'][6] = "formulize_framework_elements";
$modversion['tables'][7] = "formulize_framework_links";
$modversion['tables'][8] = "formulize_menu_cats";
$modversion['tables'][9] = "formulize_saved_views";
$modversion['tables'][10] = "group_lists";
$modversion['tables'][11] = "formulize_other";
$modversion['tables'][12] = "formulize_notification_conditions";
$modversion['tables'][13] = "formulize_valid_imports";
$modversion['tables'][14] = "formulize_screen";
$modversion['tables'][15] = "formulize_screen_multipage";
$modversion['tables'][16] = "formulize_screen_listofentries";
$modversion['tables'][17] = "formulize_entry_owner_groups";
$modversion['tables'][18] = "formulize_application_form_link";
$modversion['tables'][19] = "formulize_applications";
$modversion['tables'][20] = "formulize_screen_form";
in sql/mysql.sql
CREATE TABLE `formulize_advanced_calculations`
CREATE TABLE `formulize_applications`
CREATE TABLE `formulize_application_form_link`
CREATE TABLE `formulize_group_filters`
CREATE TABLE `formulize_groupscope_settings`
CREATE TABLE `formulize_screen_listofentries`
CREATE TABLE `formulize_screen_multipage`
CREATE TABLE `formulize_screen_form`
CREATE TABLE `formulize_screen`
CREATE TABLE formulize_valid_imports
CREATE TABLE formulize_notification_conditions
CREATE TABLE formulize_other
CREATE TABLE formulize_saved_views
CREATE TABLE group_lists
CREATE TABLE formulize_menu_cats
CREATE TABLE formulize_frameworks
CREATE TABLE formulize_framework_links
CREATE TABLE formulize_id
CREATE TABLE formulize
CREATE TABLE formulize_menu
CREATE TABLE formulize_entry_owner_groups
The net effect of installing and uninstalling the module is this
Deleting module tables...
Table icms_formulize dropped.
Table icms_formulize_id dropped.
Table icms_formulize_menu dropped.
ERROR: Could not drop table icms_formulize_reports.
Table icms_formulize_frameworks dropped.
ERROR: Could not drop table icms_formulize_framework_forms.
ERROR: Could not drop table icms_formulize_framework_elements.
Table icms_formulize_framework_links dropped.
Table icms_formulize_menu_cats dropped.
Table icms_formulize_saved_views dropped.
Table icms_group_lists dropped.
Table icms_formulize_other dropped.
Table icms_formulize_notification_conditions dropped.
Table icms_formulize_valid_imports dropped.
Table icms_formulize_screen dropped.
Table icms_formulize_screen_multipage dropped.
Table icms_formulize_screen_listofentries dropped.
Table icms_formulize_entry_owner_groups dropped.
Table icms_formulize_application_form_link dropped.
Table icms_formulize_applications dropped.
Table icms_formulize_screen_form dropped.
In addition, the following tables are left behind -
icms_formulize_advanced_calculations
icms_formulize_group_filters
icms_formulize_groupscope_settings
I haven't looked into this any further to see which tables are actually needed, so I don't have any suggestions on which to change - the xoops_version file, or the sql file.
Steve K
Christian Web Resources
p.s. - could I get commit access to the repository? I'd like to be able to help with a few things, when possible. My sf username is skenow
SQL file is authoritative. You have commit access now.
Hi Steve,
The SQL file is the one that is right. The xoops_version.php file should be updated. Although, people who have older copies of the module will have some of those tables. I am loathe to drop them automatically in an update process, deleting data should be up to the admin of the site, and what if there's a problem and they need to revert, etc, etc.
Furthermore, the framework_elements table has critical information in it for backwards compatibility, namely all the framework handles. So although it's not part of new installs, it must be kept around in old installs.
So basically, there's no clean answer to this that works in all cases. But in general, the xoops_version.php file is out of date.
You have commit access in SVN now. You may also want to subscribe to the mailing list to be notified of new commits: http://lists.freeformsolutions.ca/mailman/listinfo/formulize-commits
Thanks!!
--Julian
SQL schema updated in xoops_version
I have added the 3 tables to xoops_version that were not dropped by the uninstall process.
Yeah, trying to always to conscious of what happens during a upgrade process can be difficult, but I'm of the opinion you do what you can to help the user without taking the ownership away from them for being responsible for their own data. I had to deal with the same thing in SimplyWiki when I changed the db schema for performance reasons.
Do you have any coding standards to follow? I don't want to make changes that don't match your needs. I know you are striving for cross platform compatibility, so the standards may vary from what I'm used to.
I've done some work on simple changes to clean up files, making them smaller and less memory intensive and improving performance - the xoops_version file is one place. Instead of all this -
<?php// Tables created by sql file (without prefix!)
$modversion['tables'][0] = "formulize";
$modversion['tables'][1] = "formulize_id";
$modversion['tables'][2] = "formulize_menu";
$modversion['tables'][3] = "formulize_reports";
$modversion['tables'][4] = "formulize_frameworks";
$modversion['tables'][5] = "formulize_framework_forms";
$modversion['tables'][6] = "formulize_framework_elements";
$modversion['tables'][7] = "formulize_framework_links";
$modversion['tables'][8] = "formulize_menu_cats";
$modversion['tables'][9] = "formulize_saved_views";
$modversion['tables'][10] = "group_lists";
$modversion['tables'][11] = "formulize_other";
$modversion['tables'][12] = "formulize_notification_conditions";
$modversion['tables'][13] = "formulize_valid_imports";
$modversion['tables'][14] = "formulize_screen";
$modversion['tables'][15] = "formulize_screen_multipage";
$modversion['tables'][16] = "formulize_screen_listofentries";
$modversion['tables'][17] = "formulize_entry_owner_groups";
$modversion['tables'][18] = "formulize_application_form_link";
$modversion['tables'][19] = "formulize_applications";
$modversion['tables'][20] = "formulize_screen_form";
?>
We can do this -
<?php// Tables created by sql file (without prefix!)
$modversion['tables'] = array(
"formulize",
"formulize_id",
"formulize_menu",
"formulize_reports",
"formulize_frameworks",
"formulize_framework_forms",
"formulize_framework_elements",
"formulize_framework_links",
"formulize_menu_cats",
"formulize_saved_views",
"group_lists",
"formulize_other",
"formulize_notification_conditions",
"formulize_valid_imports",
"formulize_screen",
"formulize_screen_multipage",
"formulize_screen_listofentries",
"formulize_entry_owner_groups",
"formulize_application_form_link",
"formulize_applications",
"formulize_screen_form",
'formulize_advanced_calulations',
'formulize_group_filters',
'formulize_groupscope_settings',
);
?>
The other sections in the file would be treated similarly. It takes some getting used to, if you're used to the old style, but this is definitely a boost for the performance and memory usage.
Steve K
Christian Web Resources
You can also follow me on Twitter
So guys what does this means
So guys what does this means for me. I have basically completed a good size project on this module that is to go live in a couple of weeks. I has taken several months of work. Please I need your opinions like now for me to make a quick decision whether to use or drop the project and/or find another solution.
thanks.
btesec
It's only an issue when uninstalling the module
Hello,
The issue comes when uninstalling the module, because XOOPS/ImpressCMS will try to drop your tables, and it looks in xoops_version.php to figure out which tables to drop.
The xoops_version.php file is just not up to date with the complete list of tables that Formulize uses. That's all. No effect on any existing applications or systems.
If you're considering an upgrade to version 4...it should be no problem, but if you've got a working app that you're happy with in version 3, there's no need to upgrade. It is certainly always safer to do nothing.
Version 4 does offer some new administration features, but nothing major for end users, so there aren't really major features that you'll be missing.
--Julian
Thanks Julian, I have been
Thanks Julian,
I have been updating from the svn as I see changes happen and up to now all has gone well, i have tested the app again and again to ensure things are not broken in the app. I have always mentioned to you about having you preview my work using this mod, well that's coming soon. I am happy to see formulize project moving forward and hope that this project is here to stay for the long run.
My greatest wishes is the file attachment feature and ability to create calculation based on multiple tables/columns in a more visual manner probably ajax can help here. An of course I see there are plans to improve the user/front end interface experience.
The ability to combine at least two frameworks (by this is mean linking three forms instead of only two) since I have come across that scenario.
So to you and your team Julian I say KUDOS and THANKS for this wonderful application. It's one of the few i have come across for this type of environment especially for xoops platform.
Thanks for the Kudos. :-)
Thanks! Some things in response....
You can link more than two forms in a framework. Sort of. You can specify as many linkages as you want. But you can only "view" the framework from one point of view, ie: there is one main form, and the entries in other forms are pulled in based on the defined relationships to the main form.
What is the three form scenario you've got? It may be addressed already.
For calculations based on multiple tables/columns....that's really what the new and unfinished Procedures feature is for. The editor isn't visual. But it does give you the ability to make arbitrarily complex calculations. Or it will when it's all done.
Formulize is definitely here to stay. At the very least, as long as Freeform Solutions has clients and partners who are using Formulize, then we're going to be standing behind the development. And we have no plans to migrate clients away from it, so there's no end in sight. :-)
--Julian
You can link more than two
You can link more than two forms in a framework. Sort of. You can specify as many linkages as you want. But you can only "view" the framework from one point of view, ie: there is one main form, and the entries in other forms are pulled in based on the defined relationships to the main form.
>>>>Yes Julian I have done such views setup where I have linked about four forms together to display full data views, in this scenario it would be great to have some ajax implemented so a user can choose which sub-form details/entries he would like to see by expanding/close entries button next to each form in a framework scenario. I think there is a specific term used for this in other RAD tools. Probably I am pushing too much here, but would be a fantastic functionality.
------------------------------
What is the three form scenario you've got? It may be addressed already.
>>>>The Three forms scenario is as follows;
I am building an app for tracking autos, and auto repair jobs on each auto, and I need to make entries to track all items used for each repair job so people can go back into the system and see all items that were used for a specific job.
I know I can create two frameworks to accomplish this as follows:
Framework for:
1. auto + Repair job
2. Repair job + items used
The idea:
It will make it easier/user-friendly for end users if they would be able to make and entry for a repair job and be able to add items used for this job without having to go to another framework of forms. The reason is that there are more than one mechanic shop with more than one mechanic that can make entries at anytime for any repair job, so if a mechanic has to make an entry for a job then go to another pair of form to enter the items used for that job they might tend to forget the ID of that job. So by having the ability to enter a job and at the same time enter the items used for that job it will help avoid such issue.
This is just one of the scenarios I have come across.
-----------------------------
For calculations based on multiple tables/columns....that's really what the new and unfinished Procedures feature is for. The editor isn't visual. But it does give you the ability to make arbitrarily complex calculations. Or it will when it's all done.
>>>>Sounds great and can't wait to learn how to use it. For us non-programmers life is great with visual tools compared to having to know and programming to accomplish a task. However I do understand that not everything is just spoon-feeding in life.
----------------------------------
Formulize is definitely here to stay. At the very least, as long as Freeform Solutions has clients and partners who are using Formulize, then we're going to be standing behind the development. And we have no plans to migrate clients away from it, so there's no end in sight. :-)
>>>>>>Thanks for the commitment and at very least i hope to test and help with ideas, and hopefully help attract formulize users.
Interesting three form scenario there
Hello,
The three form scenario you outlined is interesting, I tend to plan these things out in terms of the screens that I want people to interact with. Sometimes custom buttons are an important part of that design.
Anyway, I don't see why you couldn't have people interacting only with the Repairs plus items framework. The autos is presumably just linked to the repairs through a linked selectbox? So in the repair form, you can select which auto, and then if you're working with the repair form as part of the repairs+items framework, then you can also add in items through the "subform" interface. That's how I would approach it, but I may be misunderstanding some of the other constraints you've got.
--Julian
Re: Coding standards
There is nothing strict about the style and standards in the Formulize codebase...it's had some variations over time. About the only things I'd say are "standards" are having opening braces at the end of lines, not on their own line, camelCaseForNames of things, two space tabs. That's all that leaps to mind, and those are not strictly adhered to throughout the entire codebase.
--Julian
I see that indentation isn't
I see that indentation isn't consistent in the various files - do you want spaces instead of tabs? For Drupal, 2 spaces is the standard, in ImpressCMS we use tabs.
Definitely agree with the opening brace on the same line. The Zend standard works pretty well for us, but we've made some modifications (tabs instead of spaces is one) - http://community.impresscms.org/modules/smartsection/item.php?itemid=502
~Steve
I'm really not picky about most of this stuff
I suppose if I had to pick, I'd say tabs, and people should be able to configure their editors to show tabs as however many spaces they prefer. But life isn't that simple in practice, editors aren't that smart. Anyway, since there's no consistency for now, I'd say the preference is simply for two space tabs, either as real tabs or spaces. Whatever works for you. I use Komodo as my IDE, and hit the tab key often and it autofills in indentation, so whatever Komodo actually encodes the files as, that's probably the default I'd go with. You can check a recent file, like just about anything in the admin/save folder, to see what seems standard.
--Julian
Select box (dropdowns and list boxes) data not displaying
Hi Julian,
I noticed after upgrading for the last two times from the svn (I am currently using the svn updates as of today) that data from Select box (dropdowns and list boxes) fields are not displaying when viewing the list of entries. To be able to display the data from these fields I have to create a duplicate of the same field and keep the duplicate blank.
Any fix is welcome.
thanks,
btesec
You mean the text is not clickable in the list of entries?
This is an option in the element settings now. It defaults to off, because the client who wanted it wanted it done that way. But you can change it to "on" for any selectbox, on the Options tab for that element.
If you're talking about something else, I'm not sure what the issue is. When you say "data from Select box fields are not displaying" you mean they're blank?
--Julian
Submitted the error explanation in PDF
Hi Julian,
I sent you the graphical explanation in a pdf file. hope it helps in figuring out the issue.
errors submitted
Hi Julian I submitted a list or errors to your email since I noticed the list was lengthy.
Ok, things have fallen apart
Ok, things have fallen apart now. Conditions are not working. If I set a condition on a field it does not display even if the condition is met. when I remove the condition then the fields display, I have tried possible options but not working.
Linked selectboxes?
If you're setting the conditions involving linked selectboxes, it could be that the conditions are not taking the link into account. That code might be looking for literal values in the database, but in fact the value in the database for linked selectboxes is a reference to another entry in another form. That's all I can think of off the top of my head.
If you can give the exact condition you're applying, to what kind of field, what the options are in that field, etc, that will help narrow this down. Conditions are used in a few places in Formulize, I assume you mean conditions on displaying elements, but maybe it's somewhere else? (Permissions, multipage screens, etc?)
--Julian
"If you're setting the
"If you're setting the conditions involving linked selectboxes, it could be that the conditions are not taking the link into account. That code might be looking for literal values in the database, but in fact the value in the database for linked selectboxes is a reference to another entry in another form. "
Yes Julian, the pull down list comes from another form element/field. Hopefully this can be fixed. How are the vacations going, Happy New Year to You All!
Maybe get around this with a derived value field?
I'm back now from vacation. From what I can tell, the issue here is that you have an element in a form, and you're setting a condition on whether it should be displayed. And that condition is pointing at a linked selectbox. And the condition does not appear to be working?
So that is almost certainly because the class/elementrenderer.php file does not have code that recognizes how to assess the underlying value of a linked selectbox...conditions are only supported right now for "first level elements" ie: it doesn't go back a step to the source of a link. It's probably not too hard to add that in though. The relevant code starts around line 310 in that file I think.
I think the easiest work around at the moment would be to use a derived value field to replicate the value of the linked selectbox, and then base your condition on that. ie: make a derived value element with a formula like this: $value= "name of linked selectbox"
And then base your condition on that derived value element, because it will contain the actual human-readable value of the linked selectbox, instead of the underlying coded value.
I hope that helps.
--Julian
resolved-Select box (dropdowns list boxes) data not displaying
Hi Julian,
I applied the recent updates (SVN450) and the issues is now resolved. I will send you another email pointing the issue on the "save" button is not working on a sub-form and as a result the data is saving.
(SVN450) updates
Hi Julian,
Really like the new interface, but have noticed a few issues including Select box (dropdowns list boxes) data not displaying described above. I would like to install the latest updates before I continue, what do you recommend?
got it
found them on sourceforge.net
dropdowns work and forms save.
will be testing further:)
Save button is disabled
Hi Julian,
Thanks for the quickly fixing the issues where pulldown lists field data were not displaying. I have another issue where one of the subforms is not "saving" the data when the save button is clicked. However when I clik "all done" button the "You have not saved your changes! Is that OK? Click 'Cancel' to return to the form and then click 'Save' to save your changes. " appears i click "ok" then the form returns to the main form anyway. The data however is saved.
after you log in from the header menu of the demo site:
go to Assets -> Equipment Log
I turn off the site but you can still login.
any help is welcome.
Thanks
btesec
Maybe a permission issue?
Hi Byron,
I have checked this out finally. On your fid=31&frid=32 page, I can see a subform for entries, and I can save changes in the subform. I'm thinking this may be a permission issue, the users who are having this problem don't have permission to modify the entries in the subform? That's all I can thinking of off the top of my head. Without being able to replicate the issue, it's a bit of a stab in the dark.
Does that do the trick?
--Julian
Notifacation to specific user(s)
Hi Julian,
Is there an option to send a notification to a specific user. EG. I created and entry then I want to send a notification to a specific user or selected users from my list of xoops users probable would have to have a box where I can use shift to pick/select the users I want to be notified. I think that would be helpful as I see a need for that.
thanks,
btesec
There's a workaround
Hello,
No way to actually pick a specific user, but the workaround would be to make a group for the user you want to notify, and then put that user in the group, and then setup a notification for that group.
In the SVN code we just added a feature to send a notification to an e-mail address specified in the form, like if someone enters their own e-mail address in a textbox, then you can send the notification there. But that's only in SVN right now.
--Julian
When editing or creating new
When editing or creating new entries in a framework layout i notice that after the updates are saved a blank form appears instead of just the subform being edited. I just testing from svn 487.