[Issue] Hash Cookie not resolved / Browse Form

[toms]

Hi,

In a form's js, a hash cookie is set like this (This is a simplified example - based on different conditions, another value is set):

js_browse_set_prop.png

Then it's used in the Browse Form SQL:

sql.png

When the Browse Form is opened for the first time, no rows are shown (because the previously set cookie is not resolved)
Only after hitting "Search", the "Filter" works correctly.

https://vimeo.com/256566322

[admin]

toms,

I'm not sure if this answers your question but...

It seems that you would like to filter a Browse Form at different times, for the same Edit Form.

You could create different Browse Forms that go to the same Edit Form.

redirect.PNG

http://wiki.nubuilder.net/nubuilderfort ... edirect_To

Does that help?

Steven

[toms]

Steven,

I'm well aware of this possibility. However, since my form is highly customized with javascript/php code, I'd rather not create clones of the one form to avoid redundancy and to reduce maintenance effort.
It would be so much easier if the hash cookie was resolved right away.
Is there any chance to make that work?

[admin]

toms,

OK get it now.

The problem with what you are trying to do has to do with the order nuBuilder does things...

flowchart2.PNG

The Browse is created between BB and JS

The other alternative might be to add some kind of IF() statement in your where clause.


Steven

BTW If you did redirect different Browse Forms to one Edit Form, chances are that nearly all the Javascript for your Form is for Edit and not Browse.

If so, there is probably no need to maintain any Javascript in the Browse Forms. (although that doesn't help if the Browse Forms use Before Browse)

[toms]

Steven,

Let's say I have 5 - 10 buttons on a Launch Form. Each one should run a Form with a different filter set (the restriction may be based on permissions).
Having 10 Browse Forms would be the worst case scenario since my Browse Form also contains code that needs maintaining.

Fortunately, I have now come up with a solution, even though it is not my preferred one and hopefully there is going to be a better way in the future.

Roughly described, each button sets a storage item which is then retrieved in the form's JavaScript section and then nuSetProperty() is used to set a hash cookie.
After that, a check is done if the browse_sql still contains any hashes. If there are still any, the actual search is started by calling nuSearchAction();

[admin]

toms,

Have you tried adding your filter to the Run Object?

http://wiki.nubuilder.net/nubuilderfort ... #Tab_-_Run

run.PNG

BTW there is another Github update.


Steven

[toms]

Steven,

Have you tried adding your filter to the Run Object?

I have considered that option and in some cases it makes sense to use it.
On the other hand, especially when the search string is short, and since the where clause is built to match any field, unwanted rows might be returned.

Code: Select all

(field1 LIKE  "%mystring%" OR field1 LIKE  "%mystring%" OR field3 LIKE  "%mystring%")

BTW there is another Github update.

What exactly has changed? As far as my problem is concerned, I don't see any change in behaviour.

[admin]

toms,

There was a bug with the way Run Objects applied filters.

But its all fixed now.

If you created a hidden Browse Column that held a string of 'xxx' + group (for example).

The filter on your Run Object could be 'xxxhome'.


Steven

[toms]

If you created a hidden Browse Column that held a string of 'xxx' + group (for example).
The filter on your Run Object could be 'xxxhome'.

I'm using this prefix- 'technique' in some of my forms too where I filter just by one criteria.
In my other form, the search string is a more complex expression. (Like a = xxx but not yyy).
There I use my 'ugly' workaround.

[admin]

.