fmwebschool.com
Top Experts [learn more]Top 4-10
webko

9743 K
bandmandq

2458 K
Genx

1525 K
4. tcmeyers
5. kbata
6. Martie
7. Hammerton
8. rrenfrow
9. bneeman
10. plegler
Welcome, Guest. Please login or register.
April 20, 2014, 09:32:20 PM

Login with username, password and session length
Search:     Advanced search
Welcome to the FileMaker Web Masters Exchange.  If you have any questions about how to use this forum, please watch the getting started movie at:
http://www.fmwebschool.com/movies/forum1/forum1.html
27742 Posts in 6134 Topics by 1525 Members
Latest Member: alkyred
* Home Help Search Calendar Login Register
+  fmwebschool.com
|-+  FMStudio
| |-+  FMStudio
| | |-+  Aotp enter or Lookup not working
0 Members and 1 Guest are viewing this topic. « previous next »
Pages: [1] Print
Author Topic: Aotp enter or Lookup not working  (Read 2861 times)
fmpdan
Jr. Member
**
Offline Offline

Posts: 96


Live One Day At A Time


« on: January 13, 2010, 10:49:50 AM »

I am using FM Studio Pro to submit a form with city and zip code. I have tried both and auto enter lookup and auto enter calculation so it would look up the state. This of course works fine in FMP but from the web the field for state remins blank. I can of course add the state as a value list to the form but hoped to avoid it since I figure FMP should be able to handle this. Any thoughts? Page is attached. ( in this case its using the portal wizard which works fine for entering the record (s).)

* welcome_members_company.php (5.98 KB - downloaded 139 times.)
Logged

'We create the world in which we live: if that world becomes unfit for human life, it is because we tire of our responsibility.'
Cyril Connolly 1938
fmpdan
Jr. Member
**
Offline Offline

Posts: 96


Live One Day At A Time


« Reply #1 on: January 14, 2010, 12:21:25 PM »

OK a little more information on this but still no joy.

I tried making this field a lookup but it did not work I also tried basing it on a simplified version of the relationship so it is just a zip code to zip code match. I guess I could trigger a script after the portal save changes that gets the record set and loops through setting the state and city if it is empty. The only problem with that is, where to I trigger it so the portal set comes back with the reset data?

And I would still like to understand why it does not work.

So far no one seems to have an answer. Plenty of looks but no reply.
Sad.
Logged

'We create the world in which we live: if that world becomes unfit for human life, it is because we tire of our responsibility.'
Cyril Connolly 1938
webko
Global Moderator
Hero Member
*****
Offline Offline

Posts: 2103
Kudos: 9743



WWW
Applications:
« Reply #2 on: January 14, 2010, 03:00:43 PM »

Well, if you're relying on it to do the lookup/auto-enter, then submitting an empty state field from that form will overwrite the value - try removing the state field and see if you get the lookup to work then...
Logged

tim.webko_at_gmail.com
fmpdan
Jr. Member
**
Offline Offline

Posts: 96


Live One Day At A Time


« Reply #3 on: January 15, 2010, 04:03:05 PM »

Well that sounded like a good idea but it still does not work. I wasn't inputing the state in the membership form. In the portal I took out the state from the submit and left in city and zip. I end up with no value in state or city.

I even took off the don't evaluate if all fields were empty to see if that helps but it doesn't.

If I set the fields in the DB and then type in the City in the portal and resubmit it stays. If I don't do that extra step of adding it into the portal and the DB then it removes the city but leaves the state. The difference on those two fields is state uses the relationship zip to zip
city uses the relationship zip to zip and key-D to city type where both values are "D"

I am about ready to give up and just add the state back in and city and put a case statement so it does not trigger the auto enter is the submit comes from the web

This seem like a bug tome in FMP I'll check on other lists to to see if anyone else is seeing this.

So it appears that the auto enter calculation is triggering but not entering a value
Logged

'We create the world in which we live: if that world becomes unfit for human life, it is because we tire of our responsibility.'
Cyril Connolly 1938
ptcruiser
Jr. Member
**
Offline Offline

Posts: 47


« Reply #4 on: August 10, 2011, 03:22:25 PM »

Hi Dan,

Did you ever figure out a work around for this. I am bumping up against this barrier as well and I have no idea how to get the lookup info into the fields from the web. I have tried to run scripts. Tried the auto enter calculations etc...I am wondering if this is just plain impossible.
Logged
webko
Global Moderator
Hero Member
*****
Offline Offline

Posts: 2103
Kudos: 9743



WWW
Applications:
« Reply #5 on: August 10, 2011, 08:31:43 PM »

Really, I do this all the time... If the data is entered into the correct trigger field for the lookup, it will look up the related value...

Code?
Logged

tim.webko_at_gmail.com
ptcruiser
Jr. Member
**
Offline Offline

Posts: 47


« Reply #6 on: August 11, 2011, 09:09:04 AM »

The code is the editable portal wizard. It does not appear that the relationship lookups get triggered when updating the portal information through this method. I really like this feature of FMStudio Pro but it does have its pitfalls. I love how its possible to set up a portal in the filemaker client that for example exposes all the crews scheduled for that day. Then using the editable portal wizard creating the code to expose everything in that portal to a web page and have all the records editable with only one submit. I then take that code and segregate out all the php pieces and eliminate the whole table structure and then reconstruct it using jquery mobile to allow for collapsible menus and resizable screens and buttons that work just about anywhere. I haven't found anything that does anything quite like the editable portal wizard, have you? I would be interested to know how you tackle the multiple edit record issue. If you would like I will expose this app to you to show you what I am talking about.
Logged
webko
Global Moderator
Hero Member
*****
Offline Offline

Posts: 2103
Kudos: 9743



WWW
Applications:
« Reply #7 on: August 11, 2011, 05:36:02 PM »

For multiple record edits, I'd usually go to the child table and extract the records I want from there, including their -recid

Then I'd set up multiple rows to be editable, and submitted as an array - like (Noting I use FX.php but the concept is the same...)

Code:
        <form name="students" action="students.php" method="post" />
        <input type="hidden" name="ak" value="students_edit" />
        <input type="hidden" name="classid" value="<?php echo $classid?>" />
<table>
<tr>
<th>#</th>
<th>First name</th>
<th>Last name</th>
<th>Date of birth (optional)</td?
</tr>

<?php foreach($findStudentsData['data'] as $key=>$value)  {
//Get the -recid id
$recordPointers explode ('.'$key); 
$contact_recid $recordPointers[0];
?>

<tr>
<td><input type="hidden" name="contact_recid[]" value="<?php echo $contact_recid?>" /><?php echo $i?></td>
<td><input type="text" name="namefirst[]" value="<?php echo $value['nameFirst'][0]; ?>" /></td>
<td><input type="text" name="namelast[]" value="<?php echo $value['nameLast'][0]; ?>" /></td>
<td><input type="text" name="dob[]" value="<?php echo $value['registration CONTACT::dobString'][0]; ?>" /></td>
</tr>
<?php 
$i++;
?>

</table>
<input type="submit" name="submit" value="Edit students" />
</form>

Now we'll have an array of values on the next page to be processed:
Code:
$i = 0;
foreach ($_POST['contact_recid'] as $key => $value) {
if ($_POST['contact_recid'][$i] != "") {
$updateContact = new FX($dbHost,$port,$dbType,$conType);
$updateContact -> setDBPassword($dbPass,$dbUser);
$updateContact -> setDBData($dbName,'CONTACT: Detail');
$updateContact -> AddDBParam('-recid', $_POST['contact_recid'][$i]);
$updateContact -> AddDBParam('nameFirst', $_POST['namefirst'][$i]);
$updateContact -> AddDBParam('nameLast', $_POST['namelast'][$i]);
$updateContact -> AddDBParam('dobString', $_POST['dob'][$i]);
$updateContactData = $updateContact->FMEdit();
}
$i++;
}
Logged

tim.webko_at_gmail.com
ptcruiser
Jr. Member
**
Offline Offline

Posts: 47


« Reply #8 on: August 11, 2011, 06:42:52 PM »

Thanks for that code.  Yes I got that far but what about the add and delete records at the same time in order to mimic the complete functionality of a portal? The code then starts losing its simple elegance. 
Logged
ptcruiser
Jr. Member
**
Offline Offline

Posts: 47


« Reply #9 on: August 12, 2011, 04:13:21 AM »

I take it you could add a delete input on the front end and test for that on the back end for the delete. And for the add, place another foreach loop on the front end with blank inputs and then test on the back for no -recid? Oh by the way, I take it you are using fx.php for a good reason. What do you prefer about it? Is it really much faster as others have said? I am very interested in your experience.

Thanks for all your help as always. You are a great asset to this board.
Logged
webko
Global Moderator
Hero Member
*****
Offline Offline

Posts: 2103
Kudos: 9743



WWW
Applications:
« Reply #10 on: August 14, 2011, 03:34:13 PM »

I don't allow delete via the web. Every time I have allowed that, I spend hours doing support calls for ones that they didn't mean to delete. I use a flag for ShowOnWeb, and if it's set to No, then the public searches can't find the record. But they can put the record back if they didn't mean it.

Add, I tend to use a new page for - I'll quite often have fairly complex validation rules that need to be used for new records, where with the edit records most of that has already been done.

There are two reasons I use FX rather than the API.

One is speed - I've had 2 systems where it would work with FX but time out for the API

The other is clarity - they've made the API look sort of like the old CDML syntax, but have had to jump it through quite a few hoops to do that, so the code is generally more complex to look at and understand - and I'm a KISS person through and through...
Logged

tim.webko_at_gmail.com
ptcruiser
Jr. Member
**
Offline Offline

Posts: 47


« Reply #11 on: February 23, 2012, 10:15:28 AM »

I finally figured this one out. If your lookups do not seem to be working check the order in which your fields are updating to the server. They will update in the order that you have them on the update page. So if your lookup depends on another field being added first then if it is being updated second it just may be writing over the looked up value. I hope I explained this right.
Logged
webko
Global Moderator
Hero Member
*****
Offline Offline

Posts: 2103
Kudos: 9743



WWW
Applications:
« Reply #12 on: February 23, 2012, 02:12:02 PM »

Oh, nice one... will remember that for future reference...
Logged

tim.webko_at_gmail.com
ptcruiser
Jr. Member
**
Offline Offline

Posts: 47


« Reply #13 on: January 09, 2013, 03:29:36 PM »

Sorry to resurrect an old post but I wondered what you (Webko) thought of this as it relates to our discussion in this post.

http://blog.jsfmp.com/post/7642665075/edit-multiple-filemaker-php-records-way-faster-by-portal

Also what is the status of FX.php for FM12. Does it work with it?
Logged
webko
Global Moderator
Hero Member
*****
Offline Offline

Posts: 2103
Kudos: 9743



WWW
Applications:
« Reply #14 on: January 10, 2013, 01:44:00 PM »

Joel is a smart cookie, and I can see the usefulness of that approach for editing a lot of records at once... Most of my systems don't do that though, it tends to be one record at a time...

And FX works fine with FM12 apart from one annoying bug (which can be worked around) - for some reason FM12 returns data incorrectly *if* there is a blank portal on the layout - it will send the structural portion of the XML saying it exists, but skips it altogether in the data section, resulting in data being in the wrong places after the portal part.

FX allows you to use the alternate XML grammar, which does not have this issue. Can't remember the two XML grammar names off the top of my head though.
Logged

tim.webko_at_gmail.com
Pages: [1] Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!