unable to fire up CDD

A

aksmith

Member
Hello:
I set up a CDD in the following steps:
1. created 2 Fabrik lists (with fields):
Property Addresses (id, date_time, addresses)
Property Numbers (id, date_time, apt_id, aptnumber)

2. Added 12 addresses to Property Addresses table.

3. used csv import to populate second table - apt_id is supposed to serve as the foreign key (propertyaddresses.id)

4. In a third list (Building Rules), created a databasejoin (Building Address) and CDD (Apartment No.) elements.
Triple-checked configuration - all options are set according to the Wiki guidelines.

5. Databasejoin works a dream - but updating has no effect on the CDD.

I apologize if I have overlooked something obvious and/or simple... but I have been wrestling with this for a few days now. Once it is working, I will need to use this option in a bunch of other lists/forms.

Thank you very much!
The site is: microparlor.com (details listed in account settings).
Alan
 
Seems to be re-populating the Apt CDD, at least on the backend:

http://screencast.com/t/7fNiwC4X4

... although some of the results look wrong, with repeated Apt numbers. But that probably means your data isn't correctly normalized, or you've just got doubles up data (maybe a failed import?). The query we run when that AJAX call comes in will simply return everything on the "property numbers" table with the FK value (apt_id) of the selected building. So for the ones which are doubling up (for instance, with FK = 4) you should check your underlying table data, and see if it looks correct, and you don't have double entries in the table.

-- hugh
 
Actually, just looking at "View Data" for you the apt numbers table I can see that you have doubled up data.

Also, you might want to to use a copy of the apt numbers list which isn't joined to the property table, as the list to use for your CDD. That's just liable to confuse things.

-- hugh
 
Hugh:
The data is correct. Basically, they have a number of apartment buildings, many with the same apt. numbers (e.g. 101, 102, 103, etc.).
The numbers are assigned to the right (unique) apt_id's.
If I understand the SQL logic correctly, the CDD doesn't care what the returned data is for each FK.
In a country/cities scenario, it is possible different countries might have cities with the same name, etc. (common scenario in US from state to state).

I deleted the join on the propertyaddresses list. Dumb idea born out of desperation.

Maybe I should rebuild the lists with different names? I originally tried the CDD with pre-existing tables - after I saw that it needs Fabrik lists, I deleted them and rebuilt from scratch with the same names.
When I reset the data field in the CDD, the selects list for tables shows two 'propertyaddresses' - looks like a double registration.
The only other thing I can think of is that mysql data typing went south in the csv import.
Thank you!
Alan
 
Zeroing in on issue. On back-end, the first-field select drives 'post' with no issue.
On the front-end, looks like everything is hanging on a js error thrown by the require.js (Fabrik):
Uncaught Error: Mismatched anonymous define() module: function.... {long error message)
So the first-field select never leaves the station.
 
Updated from Github - same error in front.
Going to the require.js documentation:
If you manually code a script tag in HTML to load a script with an anonymous define() call, this error can occur.
If you manually code a script tag in HTML to load a script that has a few named modules, but then try to load an anonymous module that ends up having the same name as one of the named modules in the script loaded by the manually coded script tag.
If you use the loader plugins or anonymous modules (modules that call define() with no string ID) but do not use the RequireJS optimizer to combine files together, this error can occur. The optimizer knows how to name anonymous modules correctly so that they can be combined with other modules in an optimized file.
If you use var define; at the top of your file for jshint/jslint purposes, this will cause a problem for the optimizer because it avoids parsing files that declare a define variable, since that may indicate a script that was created by a concatenation of some scripts that use a local define.

I tried running different templates - same issue.
 
Working now with Protostar - when I have time, I'll try to locate the var define issue in the main site template (there's a lot of js in there...).
Have a great day!
 
Found the issue - for anyone working with the classie.js helper (used in most Joostrap templates, for example), there is a 'define' var that throws a spanner in Fabrik's require.js.
My (expedient) solution is the remove classie.js - not really a critical priority for me, in any case.
Hugh - would you like me to post this solution as a new thread to alert others?
-Alan
 
Sorry about the delay answering, for some reason I just spaced on seeing your responses, not sure how, as I was watching for them.

We're aware of the issue with requirejs, needing to load after anything else which creates a jQuery anonymous define. We're looking at a couple of potential solutions, but it's not as easy as one might think, as the three (now four) things we are aware of that do this (like widgetkit) use system plugins to load their stuff "last", so we get in to a competition for last place with them, and there's no easy way to win that.

So where are we at with the original issue? You asked about FK's and the CDD. Your CDD's FK, i.e. what the "observed" element stores as its value, MUST be unique, typically the INT Primary Key. You can't use anything which may occur more than once in the observed table.

-- hugh
 
Hugh:
That's very good to know - I would be more than happy to sacrifice Widgetkit at the Fabrik altar... :D
Their monolithic handling of js libs is an ongoing challenge.
As for the original issue with the CDD, it's all good. FK's are unique etc.
Thanks again - and have a great weekend!
-Alan
 
You too!

Unfortunately, widgetkit is gaining in popularity. Well, I don't mean that in a nasty way, I'm happy for the authors, it just presents problems for anyone else.

I may need to see if I can talk to the authors, and work out some mutually copacetic way of handling this. Maybe have them add a global option for them to include requirejs in their code, as the last file, and we cna add an option in Fabrik so we don't add it.

The only other approach we've tried is including requirejs from the BODY, rather than HEAD, where we currently run the actual requirejs init and handling (inserted in our system plugin, by some nasty hacky mapipulation of the output buffer) ... but that has it's own issues.

-- hugh
 
I don't see to be able to even sign up for an account without buying something.

If you'd like to post this for me:

Hi,

Hugh here, I'm one of the Fabrik developers. We've spent quite a lot of time trying to resolve this issue, but to do that, we need to ensure that require.js is loaded after Widgetkit loads it's jQuery files, and there simply isn't a way to ensure this, with the Widgetkit code as-is.

It seems that I'm unable to create an account on this forum without purchasing a subscription, so one of our clients is posting on my behalf. If any of the YOOtheme devs would be willing to work with me, I have a couple of suggestions for how this could be resolved, so we can share the J! sandbox nicely. You can reach out to me through 'aksmith'.

-- hugh
 
Done.
You may take some solace from the number of other disgruntled Widgetkit/Fabrik users on that thread.
There plenty of other presentation layer widgets out there, so it's more an issue of alerting users of the conflict - and alternatives.
 
You must log in or register to reply here.

Useful links

  • Create a Fabrik Account (Downloads)
  • Create a Forum Account
  • Fabrik Wiki
  • Fabrik 4 Changelog /Install /Upgrade
    • We are in need of some funding.
    More details.

    Thank you.

    Members online

    Total: 29 (members: 4, guests: 25)
    Back
    Top