databasejoin element fronted

[coullet]

ok, i think it's clear...
So is it possible to have a non ajax add button on database join element?

Another problem with this element (id_salle) perhaps linked: with the apply button on the form, change on this element is not saved.

There just isn't a workaround for this. We'd have to change how we name elements on forms, which would mean rewriting ... well, pretty much everything!

you're really make no effort
For my information, why did you make this choice?
For me it's a little confusing, because it mix two level (fabrik list, and mysql table).

Anyway, for the tab selection issue, try this:

https://github.com/Fabrik/fabrik/commit/f4afeffd493b4e846a0aac898ab9c2dbd2177f69

This works!

But sorry, with this update there is problem with user plugin: it don't show the edit box, only icon:

i've clear joomla and browser cache.

Oh, the new search tools in dropdown is very useful!

Thanks for all this work.

 

[cheesegrits]

ok, i think it's clear...
So is it possible to have a non ajax add button on database join element?

Another problem with this element (id_salle) perhaps linked: with the apply button on the form, change on this element is not saved.

Don't know, it could be related to having duplicate names. I'll test it with non-conflicting forms and let you know.

you're really make no effort

LOL!

For my information, why did you make this choice?
For me it's a little confusing, because it mix two level (fabrik list, and mysql table).

Because we needed a unique way of naming elements for both database queries and form elements. As you can have fields/elements named the same in different groups / lists, which then get joined in the same query ... we can't just use the short element name ... "SELECT table1.id, table2.id FROM table1 LEFT JOIN table2" will generate an "ambiguous name in field list" error, and also generate invalid HTML form ID's if you have two groups on the same form with 'id' as an id/name.

So we decided to prepend the table name to the element name, so "SELECT table1.id AS table1___id", etc ... solves the uniqueness issue in MySQL and on the form.

What we didn't foresee was having two forms on the same page, with groups built on the same table. That's because back when Fabrik was started (as "MOS forms"), we didn't have things like modal popup forms using AJAX, or forms in module positions as well as component views, etc. It was strictly one form per page. And even when we started providing those features, it is extremely rare for anyone to run in to this problem, as they very rarely have two forms on the same page which have conflicting groups in them. You are the first person this year that I can recall, and I typically run in to this issue maybe once or twice a year.

So even though we're aware of the issue, it's a very rare problem, and the overhead of changing our element naming strategy is so huge, it just isn't "cost beneficial". Not only would it mean rewriting absolutely huge amounts of code, it would invalidate every piece of custom code ever written for Fabrik, including every use of a {tablename___elementname} placeholder!

But sorry, with this update there is problem with user plugin: it don't show the edit box, only icon:

What are you user element settings?

-- hugh

 

[coullet]

Thanks for explanation!
I give up this way, and let fabrik working as he want!

However, how can i have a button let me to make this thing without ajax? with a link to "normal" form?

What are you user element settings?

I make no change on this element...

Is that you want?:

Don't know, it could be related to having duplicate names. I'll test it with non-conflicting forms and let you know.

I suspect that, because other element in the form work.
But save work well, apply take another way to save the data?

 

[cheesegrits]

I figured the user element issue out. Fixing it now.

However, how can i have a button let me to make this thing without ajax? with a link to "normal" form?

Not really, at least not within the form that will do what the Add option does - which is add the new row to the select dropdown. You can have a normal menu link to add new rows, or create a simple link in something like a calc or a display element, but it's not much use doing that as it won't add the new option to the dropdown.

You'll need to alter your workflow, so if folk need to add a new option to that join, they do it before they start filling that form in.

-- hugh

 

[cheesegrits]

OK, the user element rendering should be fixed as of this commit ...

https://github.com/Fabrik/fabrik/commit/d2b2ee562d540c22a87ddb112cbcaafb85802f8b

-- hugh

 

[coullet]

ok, fixed!


Before closing this thread, have you take a look on this?

Another problem with this element (id_salle) perhaps linked: with the apply button on the form, change on this element is not saved.

Don't know, it could be related to having duplicate names. I'll test it with non-conflicting forms and let you know.

 

[cheesegrits]

I can't replicate this. Have you tried with a form which doesn't have other issues on it?

-- hugh

 

[coullet]

It's the only element with this problem

 

[cheesegrits]

I suspect it's a side effect of the naming clashes.

So just to be clear - this doesn't happen on a popup to an entirely different form (i.e. with no table name prefixes in common, so no element name clashing)?

-- hugh

 

[coullet]

In this case it's not a popup.
It's the "normal" form, open with add/edit on the list.

 

[coullet]

Did you have a look on that?

 

[cheesegrits]

Unfortunately I can't duplicate the problem here, and I don't see any obvious reason for it on your site, so it's very hard to do anything about.

In these situations, with some "corner case" issue which only crops up on a specific instance on a specific site, about the only way we can solve it is to set up an Akeeba clone of the site locally, so we can debug it. But that incurs an extra cost, as it adds a couple of hours of overhead.

-- hugh