Lookup field as Multiple-Choice
-
- Posts: 2
- Joined: 2014-03-05 09:43
Lookup field as Multiple-Choice
I have a Support Case site where I have a main table (SUPPORT CASES) and another table with HARDWARE.
When I create a new Support Case, I have no problem in creating a Look Up field to the HARDWARE table, but can only select one option from the Drop Drow list. If I use an Options List I can check Multiple Choice.
Is it possible to do this with a Lookup Field from within AppGini, without additional change to the PHP Scripts? In my case, a SUPPORT CASE can easily be connected to several HARDWARE ID's or just one. But I prefer not to use the Options List as I can add comments to the HARDWARE records and add additional properties to this table.
Best Regards and thanks for a true gem in software
Flemming
When I create a new Support Case, I have no problem in creating a Look Up field to the HARDWARE table, but can only select one option from the Drop Drow list. If I use an Options List I can check Multiple Choice.
Is it possible to do this with a Lookup Field from within AppGini, without additional change to the PHP Scripts? In my case, a SUPPORT CASE can easily be connected to several HARDWARE ID's or just one. But I prefer not to use the Options List as I can add comments to the HARDWARE records and add additional properties to this table.
Best Regards and thanks for a true gem in software
Flemming
Re: Lookup field as Multiple-Choice
Unfortunately lookups don't yet support multiple choices ... though we'll try to implement it in future releases.
AppGini plugins to add more power to your apps:
- DataTalk is an innovative AppGini plugin based on ChatGPT that allows you to interact with your AppGini database using natural language questions, without writing any SQL. Check the demo video
- Mass Update plugin: Update multiple records at once and improve your workflow efficiency.
- Check our other plugins and get a generous discount of up to 30% when buying 2 or more plugins.
-
- Posts: 2
- Joined: 2014-03-05 09:43
Re: Lookup field as Multiple-Choice
Thanks for the reply.
I am looking forward in seeing it implemented and will work around it for now by having multiple entries of the Support Cases. It is, after all, quite easy to open an existing case and save it as a new case
I am looking forward in seeing it implemented and will work around it for now by having multiple entries of the Support Cases. It is, after all, quite easy to open an existing case and save it as a new case
Re: Lookup field as Multiple-Choice
Hi, curious to know if there is a solution for the lookup field as multiple-choice already.
-
- Posts: 3
- Joined: 2016-01-27 02:24
Re: Lookup field as Multiple-Choice
Hi,
I also need to do this for a project I'm working on. This would enable 'tagging' where you could create a table with as many 'tags' (terms) as needed and dynamically add them to another tables' records at-will. The ability to add more than on 'tag' would be super!
Is it possible to do with custom code? I would pay if reasonable costs.
Thanks,
Paul
I also need to do this for a project I'm working on. This would enable 'tagging' where you could create a table with as many 'tags' (terms) as needed and dynamically add them to another tables' records at-will. The ability to add more than on 'tag' would be super!
Is it possible to do with custom code? I would pay if reasonable costs.
Thanks,
Paul
Re: Lookup field as Multiple-Choice
Hi,
I confirm Lookup field as Multiple-Choice will be a super feature for appgini. I need too a multiple selection from a lookup table.
It seem to be possible but it is not because we need to have text in a primary key and it is not possible with MySQL.
I confirm Lookup field as Multiple-Choice will be a super feature for appgini. I need too a multiple selection from a lookup table.
It seem to be possible but it is not because we need to have text in a primary key and it is not possible with MySQL.
Chrisagon.
Re: Lookup field as Multiple-Choice
I too could use this feature, in several projects / places. Anyone have a work around?
- baudwalker
- Veteran Member
- Posts: 188
- Joined: 2015-02-03 08:08
- Location: Bellingen NSW Australia
Re: Lookup field as Multiple-Choice
me too, please add this feature
Re: Lookup field as Multiple-Choice
Hi Ahmed,
lookup fields with the possibility to choose more than one option are pretty neat of course. I think it should be discussed (well thought over) how this is handled internally i.e. in the database, so I want to share my 2 cents.
If one would to that database wise, we would need a 1:n relation to another table, and that table holds all chosen IDs connected with the master ID from the master table. If this is handled differently, I am not so sure how people (here) want to handle this.
Putting all values into one field would probably mess up AG's functions to use the PK definition of the mastertable for the field to hold the FK - how would more than one FK be saved into such a field. Probably a textfield whould be able to hole more than one value, seperated by some identifier to the different values.
The layout would make it possible to use a html select statement with more then one line as well (user should be able to define a max lines).
I do see the sweetness of that honey pot, but I am not so sure, if "we" are aware what and of the number of problems that arise, when this kind of database entry has to be used in another database, being exported as CSV... I myself see a lot of unanswered and highly problematic questions concerning this suggestion.
As I am a "database"-creating person and would feel much happier by using a 1:n relation. AG could make it possible to choose more than one value and fill more than one record in the details table.
Olaf
lookup fields with the possibility to choose more than one option are pretty neat of course. I think it should be discussed (well thought over) how this is handled internally i.e. in the database, so I want to share my 2 cents.
If one would to that database wise, we would need a 1:n relation to another table, and that table holds all chosen IDs connected with the master ID from the master table. If this is handled differently, I am not so sure how people (here) want to handle this.
Putting all values into one field would probably mess up AG's functions to use the PK definition of the mastertable for the field to hold the FK - how would more than one FK be saved into such a field. Probably a textfield whould be able to hole more than one value, seperated by some identifier to the different values.
The layout would make it possible to use a html select statement with more then one line as well (user should be able to define a max lines).
I do see the sweetness of that honey pot, but I am not so sure, if "we" are aware what and of the number of problems that arise, when this kind of database entry has to be used in another database, being exported as CSV... I myself see a lot of unanswered and highly problematic questions concerning this suggestion.
As I am a "database"-creating person and would feel much happier by using a 1:n relation. AG could make it possible to choose more than one value and fill more than one record in the details table.
Olaf
Some postings I was involved, you might find useful:
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
Re: Lookup field as Multiple-Choice
Hi everyone!
Have you seen the great blog article: "A work-around to implement a multiple choice lookup field in your AppGini apps" ?
https://bigprof.com/blog/appgini/a-work ... gini-apps/
I think it may be a good solution to manage multiple choice lookup field!
What do you think?
Regards.
Fabiano
Have you seen the great blog article: "A work-around to implement a multiple choice lookup field in your AppGini apps" ?
https://bigprof.com/blog/appgini/a-work ... gini-apps/
I think it may be a good solution to manage multiple choice lookup field!
What do you think?
Regards.
Fabiano
Re: Lookup field as Multiple-Choice
I'd like to share my experience with you and BigProf to bring forward this feature request. I've done different workarounds with hooks for multiselect relations as you can see in this article...
viewtopic.php?f=8&t=10&p=8956&hilit=multi#p8956
... AND ...
...another solution, which is the version I'm currently using in my projects. Have a look at the following screencast:
This is not only multi select options list but data from different tables. Evertything has been done with hooks. The assignments are being saved in a relationship-table on saving the record itself.
Although I already have a working solution for my projects and customers, I'd really like to have it in AppGini standard. So +1 for this feature request!
Ahmed's article mentioned before is a really good starting point. A widely used example is the bookstore-example. A book can have multiple authors, and an author can write multiple books. Next to "books" and "authors" tables...
books
id
name
authors
id
name
...you will need a third table "books_authors" for example.
books_authors
id
book_id
author_id
In details view of a book you need an input field showing the related authors and a dropdown list suggesting the non-related authors. On saving a book, the non-related authors have to be removed from books_authors, and new authors have to be inserted in books_authors-table.
In details view of an author you need an input field showing the related books and a dropdown list suggesting the non-related books. On saving the author, the non-related books have to be removed from books_authors, and new books have to be inserted in books_authors-table.
I know by my own experience that it will be quite a lot of work for BigProf to implement that into AppGini User Interface. Those inputs have to work in two directions, for example in author detail view you need assignment of books and in book detail view you need assignment of authors. BigProf will have to consider:
Putting it altogether, it's a lot of work and scenarios to consider. It would push AppGini forward, sure, but only if it works 100%. To be honest, this is a hard task having it in standard fulfulling many of our wishes!
In my implementation there is only little code in my TABLENAME.php hooks file...
...but you can imagine there is a lot of PHP-code and JavaScript/JQuery (TypeScript in my case) behind the scene.
I hope my explanations will help pushing this requirement into AppGini 6 or so.
Kind Regards,
Jan
viewtopic.php?f=8&t=10&p=8956&hilit=multi#p8956
... AND ...
...another solution, which is the version I'm currently using in my projects. Have a look at the following screencast:
This is not only multi select options list but data from different tables. Evertything has been done with hooks. The assignments are being saved in a relationship-table on saving the record itself.
Although I already have a working solution for my projects and customers, I'd really like to have it in AppGini standard. So +1 for this feature request!
Ahmed's article mentioned before is a really good starting point. A widely used example is the bookstore-example. A book can have multiple authors, and an author can write multiple books. Next to "books" and "authors" tables...
books
id
name
authors
id
name
...you will need a third table "books_authors" for example.
books_authors
id
book_id
author_id
In details view of a book you need an input field showing the related authors and a dropdown list suggesting the non-related authors. On saving a book, the non-related authors have to be removed from books_authors, and new authors have to be inserted in books_authors-table.
In details view of an author you need an input field showing the related books and a dropdown list suggesting the non-related books. On saving the author, the non-related books have to be removed from books_authors, and new books have to be inserted in books_authors-table.
I know by my own experience that it will be quite a lot of work for BigProf to implement that into AppGini User Interface. Those inputs have to work in two directions, for example in author detail view you need assignment of books and in book detail view you need assignment of authors. BigProf will have to consider:
- table-name for the relation-table (here:books_authors)
- primary key of the relation-table (here: books_authors.id)
- foreign key column name in the relation-table pointing to the left table (book_id or author_id)
- foreign key column name in the relation-table pointing to the right table (author_id or book_id)
- table-name for the left table (books or authors)
- table-name for the right table (authors or books)
- primary key of the left table (books.id or authors.id)
- primary key of the right table (authors.id or books.id)
- display column(s) for the left table (I only support one column in my solution)
- display column(s) for the right table (I only support one column in my solution)
- filter criteria to show only certain items of the left table in the dropdown (I did not implement this in my solution)
- filter criteria to show only certain items of the right table in the dropdown (I did not implement this in my solution)
- helptext for the field in DV of left table
- helptext for the field in DV of right table
Putting it altogether, it's a lot of work and scenarios to consider. It would push AppGini forward, sure, but only if it works 100%. To be honest, this is a hard task having it in standard fulfulling many of our wishes!
In my implementation there is only little code in my TABLENAME.php hooks file...
Code: Select all
// for setup of a relationship
function wirtschaftseinheit_flurstuecke()
{
$multiselect = new \bizzworxx\ManyToManyRelation('wirtschaftseinheit_flurstuecke', 'id', 'wirtschaftseinheit_id', 'Flurstücke');
$multiselect->setRight('flurstueck_id', 'flurstuecke', 'id', 'nummer');
$multiselect->createdBy = "createdby";
$multiselect->createdOn = "createdon";
return $multiselect;
}
// for rendering the input field and dropdown in DV
function wirtschaftseinheiten_dv($selectedID, $memberInfo, &$html, &$args)
{
$flurstuecke = wirtschaftseinheit_flurstuecke();
$html .= $flurstuecke->render($selectedID);
}
// and for update...
function wirtschaftseinheiten_before_update(&$data, $memberInfo, &$args)
{
$flurstuecke = wirtschaftseinheit_flurstuecke();
return $flurstuecke->update($data, $memberInfo, $args);
}
I hope my explanations will help pushing this requirement into AppGini 6 or so.
Kind Regards,
Jan
Kind regards,
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
AppGini 24.10 Revision 1579 + all AppGini Helper tools
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
[code]...[/code]
blocks for better readabilityAppGini 24.10 Revision 1579 + all AppGini Helper tools
Re: Lookup field as Multiple-Choice
Oh, I forgot to mention:
Users expect that they can click on one of the related items and will be redirected to that record (and vice versa):
On book-DV they expect they can navigate to the related author(s), and on author-DV they expect they can navigate to the related book(s).
This may become problematic:
If the current record has been modified ("is dirty") and they navigate to a different record, the changes on the current record may get lost - unless you deny navigating to another record (or open it embedded or in a new tab which both I dislike).
This means as soon as the record gets modified, the click-handlers of the relation-buttons have to be disabled or removed.
Regards,
Jan
Users expect that they can click on one of the related items and will be redirected to that record (and vice versa):
On book-DV they expect they can navigate to the related author(s), and on author-DV they expect they can navigate to the related book(s).
This may become problematic:
If the current record has been modified ("is dirty") and they navigate to a different record, the changes on the current record may get lost - unless you deny navigating to another record (or open it embedded or in a new tab which both I dislike).
This means as soon as the record gets modified, the click-handlers of the relation-buttons have to be disabled or removed.
Regards,
Jan
Kind regards,
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
AppGini 24.10 Revision 1579 + all AppGini Helper tools
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
[code]...[/code]
blocks for better readabilityAppGini 24.10 Revision 1579 + all AppGini Helper tools
Re: Lookup field as Multiple-Choice
One more thing: Ownership of records
Jan
- After creation of a new relation (insert into relation-table) we have to set the owner.
- After removing a relation (in relation-table), we have to delete the ownership-record to avoid orphans.
Jan
Kind regards,
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
AppGini 24.10 Revision 1579 + all AppGini Helper tools
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
[code]...[/code]
blocks for better readabilityAppGini 24.10 Revision 1579 + all AppGini Helper tools
Re: Lookup field as Multiple-Choice
Hi Jan,
thank you for this deep input.
Hopefully it will be helpful.
Olaf
thank you for this deep input.
Hopefully it will be helpful.
Olaf
Some postings I was involved, you might find useful:
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
Re: Lookup field as Multiple-Choice
Another thing to consider:
On "Save as copy" of a record, I'm wondering if the relations should also be copied?!
The relations between books and authors are stored in a separate table books_authors for example. Duplicating a book-record or duplicating an author-record will not duplicate all relations automatically.
From my experience there are scenarios in which duplicating relations is important and other scenarios in which you don't want those duplicates. So in case BigProf is going to implement this, we'd need behaviour-options in AppGini for "save as copy", or we need a hook-function being called before and/or after "save as copy" where we can duplicate relations using SQL by ourselves.
Regards,
Jan
On "Save as copy" of a record, I'm wondering if the relations should also be copied?!
The relations between books and authors are stored in a separate table books_authors for example. Duplicating a book-record or duplicating an author-record will not duplicate all relations automatically.
From my experience there are scenarios in which duplicating relations is important and other scenarios in which you don't want those duplicates. So in case BigProf is going to implement this, we'd need behaviour-options in AppGini for "save as copy", or we need a hook-function being called before and/or after "save as copy" where we can duplicate relations using SQL by ourselves.
Regards,
Jan
Kind regards,
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
AppGini 24.10 Revision 1579 + all AppGini Helper tools
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
[code]...[/code]
blocks for better readabilityAppGini 24.10 Revision 1579 + all AppGini Helper tools
-
- AppGini Super Hero
- Posts: 121
- Joined: 2020-02-16 16:29
Re: Lookup field as Multiple-Choice
jsetzer wrote: ↑2019-07-01 19:13I'd like to share my experience with you and BigProf to bring forward this feature request. I've done different workarounds with hooks for multiselect relations as you can see in this article...
viewtopic.php?f=8&t=10&p=8956&hilit=multi#p8956
2018-10-17_20-56-51.gif
... AND ...
...another solution, which is the version I'm currently using in my projects. Have a look at the following screencast:
2019-07-01_20-33-31.gif
This is not only multi select options list but data from different tables. Evertything has been done with hooks. The assignments are being saved in a relationship-table on saving the record itself.
Although I already have a working solution for my projects and customers, I'd really like to have it in AppGini standard. So +1 for this feature request!
Ahmed's article mentioned before is a really good starting point. A widely used example is the bookstore-example. A book can have multiple authors, and an author can write multiple books. Next to "books" and "authors" tables...
books
id
name
authors
id
name
...you will need a third table "books_authors" for example.
books_authors
id
book_id
author_id
In details view of a book you need an input field showing the related authors and a dropdown list suggesting the non-related authors. On saving a book, the non-related authors have to be removed from books_authors, and new authors have to be inserted in books_authors-table.
In details view of an author you need an input field showing the related books and a dropdown list suggesting the non-related books. On saving the author, the non-related books have to be removed from books_authors, and new books have to be inserted in books_authors-table.
I know by my own experience that it will be quite a lot of work for BigProf to implement that into AppGini User Interface. Those inputs have to work in two directions, for example in author detail view you need assignment of books and in book detail view you need assignment of authors. BigProf will have to consider:
Additionally, if your relation-table has columns like "created_by" or "created_on", they will have to be populated, too, as soon as you have added a relation.
- table-name for the relation-table (here:books_authors)
- primary key of the relation-table (here: books_authors.id)
- foreign key column name in the relation-table pointing to the left table (book_id or author_id)
- foreign key column name in the relation-table pointing to the right table (author_id or book_id)
- table-name for the left table (books or authors)
- table-name for the right table (authors or books)
- primary key of the left table (books.id or authors.id)
- primary key of the right table (authors.id or books.id)
- display column(s) for the left table (I only support one column in my solution)
- display column(s) for the right table (I only support one column in my solution)
- filter criteria to show only certain items of the left table in the dropdown (I did not implement this in my solution)
- filter criteria to show only certain items of the right table in the dropdown (I did not implement this in my solution)
- helptext for the field in DV of left table
- helptext for the field in DV of right table
Putting it altogether, it's a lot of work and scenarios to consider. It would push AppGini forward, sure, but only if it works 100%. To be honest, this is a hard task having it in standard fulfulling many of our wishes!
In my implementation there is only little code in my TABLENAME.php hooks file...
...but you can imagine there is a lot of PHP-code and JavaScript/JQuery (TypeScript in my case) behind the scene.Code: Select all
// for setup of a relationship function wirtschaftseinheit_flurstuecke() { $multiselect = new \bizzworxx\ManyToManyRelation('wirtschaftseinheit_flurstuecke', 'id', 'wirtschaftseinheit_id', 'Flurstücke'); $multiselect->setRight('flurstueck_id', 'flurstuecke', 'id', 'nummer'); $multiselect->createdBy = "createdby"; $multiselect->createdOn = "createdon"; return $multiselect; } // for rendering the input field and dropdown in DV function wirtschaftseinheiten_dv($selectedID, $memberInfo, &$html, &$args) { $flurstuecke = wirtschaftseinheit_flurstuecke(); $html .= $flurstuecke->render($selectedID); } // and for update... function wirtschaftseinheiten_before_update(&$data, $memberInfo, &$args) { $flurstuecke = wirtschaftseinheit_flurstuecke(); return $flurstuecke->update($data, $memberInfo, $args); }
I hope my explanations will help pushing this requirement into AppGini 6 or so.
Kind Regards,
Jan
Can you please explain other php-codes and JS please.
I want to do this in my school project
Re: Lookup field as Multiple-Choice
I have already answered your request. There is no simple way to do it.
Kind regards,
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
AppGini 24.10 Revision 1579 + all AppGini Helper tools
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
[code]...[/code]
blocks for better readabilityAppGini 24.10 Revision 1579 + all AppGini Helper tools
-
- AppGini Super Hero
- Posts: 121
- Joined: 2020-02-16 16:29
Re: Lookup field as Multiple-Choice
I'm really sorry if I disturbed you. I thought that you would help me by just telling me a example. I donot want you to do my project but if you can share the example you have posted and simple code like what you have made for the hooks folder would let me understand.
Thanx in advance for the trouble I ask.
I will pay you if you need money for the help I ask
Re: Lookup field as Multiple-Choice
@sathukorala: You have been asking the same question on different forum threads now. Additionally you have sent private messages/emails to me. I have answered all your questions and requests immediately and in a friendly an polite way and I have sent a private message to you. Maybe it's because my English is not good enough.
I'm sorry if, after all, my previous answers were not clear: I don't have any copy&paste code examples and I cannot spend that necessary amount of time to prepare such for your school project.
This topic is extremely complicated. If it was easy, there would be a couple of Super Heroes here in the forum giving away 100% bullet proof AND simple to use one-liner code examples. But there aren't. It is complicated. Even my 70% solution, which a customer has ordered 1.5 year ago, has taken days for research and trial and another days for implementation. There are hundreds of lines of PHP code and another hundreds of lines JS code in multiple files (PHP classes etc).
Annotation: Why did I call my solution a "70% solution"? Please read this comlete thread. I have named several problems with user-permissions, deleting records etc..
I hope for your understanding:
Even if I was allowed to publish that customer's code, I am not able to collect all that together into one example code zip file which will be bullet-proof AND at the same time easy to use even for beginners. I simply cannot do.
Once again, I'm sorry that I cannot help you on your school project in a way you have expected me to do.
Regards,
Jan
I'm sorry if, after all, my previous answers were not clear: I don't have any copy&paste code examples and I cannot spend that necessary amount of time to prepare such for your school project.
This topic is extremely complicated. If it was easy, there would be a couple of Super Heroes here in the forum giving away 100% bullet proof AND simple to use one-liner code examples. But there aren't. It is complicated. Even my 70% solution, which a customer has ordered 1.5 year ago, has taken days for research and trial and another days for implementation. There are hundreds of lines of PHP code and another hundreds of lines JS code in multiple files (PHP classes etc).
Annotation: Why did I call my solution a "70% solution"? Please read this comlete thread. I have named several problems with user-permissions, deleting records etc..
I hope for your understanding:
Even if I was allowed to publish that customer's code, I am not able to collect all that together into one example code zip file which will be bullet-proof AND at the same time easy to use even for beginners. I simply cannot do.
Once again, I'm sorry that I cannot help you on your school project in a way you have expected me to do.
Regards,
Jan
Kind regards,
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
AppGini 24.10 Revision 1579 + all AppGini Helper tools
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
[code]...[/code]
blocks for better readabilityAppGini 24.10 Revision 1579 + all AppGini Helper tools
-
- AppGini Super Hero
- Posts: 121
- Joined: 2020-02-16 16:29
Re: Lookup field as Multiple-Choice
jsetzer wrote: ↑2020-02-22 10:08@sathukorala: You have been asking the same question on different forum threads now. Additionally you have sent private messages/emails to me. I have answered all your questions and requests immediately and in a friendly an polite way and I have sent a private message to you. Maybe it's because my English is not good enough.
I'm sorry if, after all, my previous answers were not clear: I don't have any copy&paste code examples and I cannot spend that necessary amount of time to prepare such for your school project.
This topic is extremely complicated. If it was easy, there would be a couple of Super Heroes here in the forum giving away 100% bullet proof AND simple to use one-liner code examples. But there aren't. It is complicated. Even my 70% solution, which a customer has ordered 1.5 year ago, has taken days for research and trial and another days for implementation. There are hundreds of lines of PHP code and another hundreds of lines JS code in multiple files (PHP classes etc).
Annotation: Why did I call my solution a "70% solution"? Please read this comlete thread. I have named several problems with user-permissions, deleting records etc..
I hope for your understanding:
Even if I was allowed to publish that customer's code, I am not able to collect all that together into one example code zip file which will be bullet-proof AND at the same time easy to use even for beginners. I simply cannot do.
Once again, I'm sorry that I cannot help you on your school project in a way you have expected me to do.
Regards,
Jan
So sorry that I bothered you.
I found a simple solution:
https://bigprof.com/blog/appgini/a-work ... gini-apps/
This is to everybody who had the same problem
-
- AppGini Super Hero
- Posts: 121
- Joined: 2020-02-16 16:29
Re: Lookup field as Multiple-Choice
A work-around to implement a multiple choice lookup field in your AppGini apps
https://bigprof.com/blog/appgini/a-work ... gini-apps/
https://bigprof.com/blog/appgini/a-work ... gini-apps/
Re: Lookup field as Multiple-Choice
I'm glad you have found this workaround!
To everyone who reads his recommendation above:
Anyway, I hope this solution will fullfil your requirements. If this is only for playing or simple lookups, it's fine. But in professional environments please use it with caution.
Best regards,
Jan
To everyone who reads his recommendation above:
- Please note that, with the solution recommended above, there is a serious problem with data integrity:
As soon as someone edits or deletes a master-record, all related detail records will be broken. You will have to update all details records by yourself. If you don't do this, you will have detail-records pointing to masters which do not exist any more in the database. The blog post he has mentioned above also tells about this backdraw. - Additionally, there is no linking from details to master-records, so if you click on a selected value, the selected record will not be opened in the browser. It is just showing the names of the master-records.
- Also, you cannot control user permissions. All items will be listed and can be selected - even if users do not have the permission to see them.
Anyway, I hope this solution will fullfil your requirements. If this is only for playing or simple lookups, it's fine. But in professional environments please use it with caution.
Best regards,
Jan
Kind regards,
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
AppGini 24.10 Revision 1579 + all AppGini Helper tools
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
[code]...[/code]
blocks for better readabilityAppGini 24.10 Revision 1579 + all AppGini Helper tools
-
- AppGini Super Hero
- Posts: 121
- Joined: 2020-02-16 16:29
Re: Lookup field as Multiple-Choice
Thank you for your feedbackjsetzer wrote: ↑2020-02-22 10:43I'm glad you have found this workaround!
To everyone who reads his recommendation above:
As a software professional developer, I cannot recommend it without knowing the specification. Especially not, if this is a school project for teaching someone about data, data-security and data-integrity. Very often people have to fail and collect their own experiences before they can see and understand the limits and backdraws, the advantages and disadvantages of a given solution.
- Please note that, with the solution recommended above, there is a serious problem with data integrity:
As soon as someone edits or deletes a master-record, all related detail records will be broken. You will have to update all details records by yourself. If you don't do this, you will have detail-records pointing to masters which do not exist any more in the database. The blog post he has mentioned above also tells about this backdraw.- Additionally, there is no linking from details to master-records, so if you click on a selected value, the selected record will not be opened in the browser. It is just showing the names of the master-records.
- Also, you cannot control user permissions. All items will be listed and can be selected - even if users do not have the permission to see them.
Anyway, I hope this solution will fullfil your requirements. If this is only for playing or simple lookups, it's fine. But in professional environments please use it with caution.
Best regards,
Jan
Can you at least help me please with a code to
the tags_before_update() hook to get the old value of the tag and perform a search and replace operation to the products.tags field.
and
to handle deleting tags, a code to the tags_before_delete() hook to also search for that tag in products.tags and clear it. ?
Re: Lookup field as Multiple-Choice
Warning (1)
A word or warning to those who are going to follow that recommended soluton:
Example
master-table
details-table
Change record #1 and rename "Peter" to "Alexander"
master-table (after changing #1)
We expect that our details-record will NOT be touched, because we have selected #2 and #3 but we have renamed #1. This should not have an impact on our details record.
But what does search&replace do
The reason is, that the id's are not being stored when using the multiselect option which is available in current version of AppGini.
Conclusion:
Be careful with this solution if your app is more than just a playgound!
A word or warning to those who are going to follow that recommended soluton:
Example
master-table
- id=1, name="Peter"
- id=2, name="Paul"
- id=3, name="Peter"
details-table
- id=1, values="Peter, Paul"
Change record #1 and rename "Peter" to "Alexander"
master-table (after changing #1)
- id=1, name="Alexander"
- id=2, name="Paul"
- id=3, name="Peter"
- Find all records having "Peter" in values field
- replace "Peter" by "Alexander" in values field
We expect that our details-record will NOT be touched, because we have selected #2 and #3 but we have renamed #1. This should not have an impact on our details record.
But what does search&replace do
- It will find "Peter" in our details-table
- It will rename "Peter" by "Alexander". So the final result will be:
- id=1, values="Alexander, Paul"
The reason is, that the id's are not being stored when using the multiselect option which is available in current version of AppGini.
Conclusion:
Be careful with this solution if your app is more than just a playgound!
Kind regards,
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
AppGini 24.10 Revision 1579 + all AppGini Helper tools
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
[code]...[/code]
blocks for better readabilityAppGini 24.10 Revision 1579 + all AppGini Helper tools