What is datasource for detailview and print ($options->????)

If you're a new user of AppGini, feel free to ask general usage questions, or look for answers here.
Post Reply
User avatar
onoehring
AppGini Super Hero
AppGini Super Hero
Posts: 1156
Joined: 2019-05-21 22:42
Location: Germany
Contact:

What is datasource for detailview and print ($options->????)

Post by onoehring » 2021-02-23 08:57

Hi,

we can have a vast influence on the data that is shown to the user ... good.
I am able to tweak data in the /hooks/tablename.php -> _init function for
  • tableview by changing $options->QueryFieldsTV
  • CSV by changing $options->QueryFieldsCSV
But: What is the source for data in detailview and print?

Olaf

User avatar
onoehring
AppGini Super Hero
AppGini Super Hero
Posts: 1156
Joined: 2019-05-21 22:42
Location: Germany
Contact:

Re: What is datasource for detailview and print ($options->????)

Post by onoehring » 2021-03-01 07:45

Hi,

just wondering if my question is so akward, that noone can answer it. If so I would believe, there is no way to influence the data for detailview and print, and I would post a feature request.

Olaf

User avatar
jsetzer
AppGini Super Hero
AppGini Super Hero
Posts: 1807
Joined: 2018-07-06 06:03
Location: Kiel, Germany
Contact:

Re: What is datasource for detailview and print ($options->????)

Post by jsetzer » 2021-03-01 09:08

Hi Olaf,

honestly speaking, when I read your post, I did not really understand your question: The datasource for DV is defined by your table-model based on the master table, optionally joined with lookup-tables, filtered by primary key, limit 1.

I don't understand why you would like to modify the shown information for DV in a RAD/CRUD tool like AppGini, as the DV is just a graphical presentation of the record + additional information coming from detail tables.

Fortunately, AppGini already gives us so many possibilities by providing hooks, templates (for DV and even DVP) and data formats.

We are free to add additional information in PHP or Javascript, even lazy loaded using AJAX. With all these options, you can even solve very, very project-specific requirements, which probably are not relevant for the majority of users.

Maybe you should explain your aim and we will be able to point you to the right direction. What do you want to achieve? Why do you want to display different data than stored in your table? Why can't this be done using data formats, SQL-formatting calculated fields or other built-in features?

Sorry, if I did not understand the problem completely!
Kind regards,
<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 readability

AppGini 24.10 Revision 1579 + all AppGini Helper tools

User avatar
jsetzer
AppGini Super Hero
AppGini Super Hero
Posts: 1807
Joined: 2018-07-06 06:03
Location: Kiel, Germany
Contact:

Re: What is datasource for detailview and print ($options->????)

Post by jsetzer » 2021-03-01 09:58

Custom pages

I forgot to mention:
We can also create cutstom pages and in there we are completely free what to display and how.

I sometimes read posts here where developers would like to change table view or detail view completely for solving very specific requirements or UI-wishes. Sometimes those requests would turn standard AppGini views upside-down, and, honestly speaking, I'm not a friend of this, because AppGini has to stay compatible with thousands of projects worldwide, from my point of view.

Anyway: Yes, we can do so with custom pages and other built-in features. And yes, this requires certain skills. It is possible with the AppGini software-features we have paid for.

Personal annotation

As always: If we decide to leave the standard trail, we will have to spend time and/or money on individual customizations. But it is our personal decision for leaving the standard. Personally, I prefer keeping the standard as much as possible for future compatibility on updates. So I make use of the features named in my previous post and of custom pages, if necessary.

Often, I have to step back, overthink my first ideas and then solve the given requirement by using one of the given standard options. I have purchased AppGini with a given set of possibitlities. So I try to achieve my goal by using the given features instead of expecting the tool to solve everything out of the box. No tool on earth will do this for me. We always have to make the best of what's given.

So, many times it is my job to re-think my ideas until they fit into the standard. And mostly it is not Ahmed's job to solve every of my project-specific requirements. Major changes could probably crash thousands of existing projects, including mine. For example, I have seen discussions about unique e-mail addresses and datatype of memberID or about forcing strong passwords even on localhost. I'm really worried when I see this, because many of us have purchased AppGini for several reasons and features, for example for simplicity, automatic data migrations, hooks or browser-compatibility. If BigProf would start changing such elementary, basic principles and force us to apply those, this would probably crash thousands of projects on next update. For me, future compatibility is very, very important when thinking about my development-toolchain. I have to rely on future compatibility and I would like to encourage others to overthink specific feature requests which could solve one problem but may create tenthousands of follow-up problems for others.

But that's just my personal opinion.
Kind regards,
<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 readability

AppGini 24.10 Revision 1579 + all AppGini Helper tools

User avatar
onoehring
AppGini Super Hero
AppGini Super Hero
Posts: 1156
Joined: 2019-05-21 22:42
Location: Germany
Contact:

Re: What is datasource for detailview and print ($options->????)

Post by onoehring » 2021-03-01 11:52

Hi Jan,

thank you very much for such an elaborated answer. But well, I will try to clear things a little and this will hopefully show why I am asking.
The "extension" I developped Field Permissions (hide / lock fields by usergroup) (viewtopic.php?f=4&t=3308&start=25) checks if the user is on TV or DV (or mixed) and inserts code/adjusts data. There are two possibilities.
a) a field can be LOCKED, so a user can not change the contents or
b) a field can be HIDDEN (which also locks the field, but in TV and DV the user does not see the field).

Everything works fine in TV (view, print, csv export: HIDDEN fields are not available to the user, LOCKED fields do not matter in TV).
But user hubert encountered, that in DV, while HIDDEN data is hidden and the user can not see it, the data IS shown when the user prints the records/goes to print preview.

So the reason for me asking is, that I want to improve the extension that HIDDEN data is also completely unavailable in DV / print. Currently I am using your AG Helper to hide fields in DV, but it would be better to remove them completely .... and as I am targeting some kind of easy-to-install-extension, I am trying to prevent hacking the generated print pages (/templates/tablename_templateDVP.html), but simply "removing" (/overwriting) the content from the record for DV and print.

I hope the reason for my question is more transparent now.

Olaf

Post Reply