Jump to content

Martin Brändle

  • Posts

  • Joined

  • Last visited

About Martin Brändle

  • Birthday 12/25/1965

Profile Information

  • Gender
    Not Telling

Martin Brändle's Achievements


Experienced (11/14)

  • First Post
  • Collaborator
  • Posting Machine Rare
  • Conversation Starter
  • Week One Done

Recent Badges



  1. An answer that might help him and others who search and read later this forum. That's why I also answer to posts that are not current. Of course there are many ways (or procedures) for tab substitution. And one can also do with XSLT only, as you mentioned. But the problem here is that one can't use the translate() function, because it replaces only char-by-char, but one needs to substitute tab by several spaces, and that maybe several times. With XSLT 1.0, this can only be done using recursion. That's why I suggested to use FM's Substitute() function (as a quick fix). It's more powerful than several lines of XSLT code for doing the same thing. See XSLT recursion examples on http://www.dpawson.co.uk/xsl/sect2/replace.html
  2. Ah yes? Then why did you give not the right answer four months ago?
  3. Yes, that's too much. The bottleneck is the AJP connector between Apache 1.3 and the Tomcat component of the WPE. Maybe with Apache 2 it is better.
  4. You need either XSL-FO (formatting objects) and the corresponding XSL processor (Apache FOP); but probably then you are on your own here and can't get much help from this forum. Or you change to PHP CWP and the corresponding pdf libraries.
  5. Yes, XSLT recognizes the tabs as whitespace. What you could do is the following: Use a calculation field and the FM Substitute function to replace the tab character with the amount of spaces you desire. In the XSLT, output the content of the calculation field with tags around.
  6. What do you mean with "sync"? Are there already records available in your FM catalog?
  7. Yes, your loop runs through the wrong part of your XML tree. It should run through the records. It should look like: �
  8. I think the problem lies in your test in the alumProdSum template.
  9. Are your images stored in FileMaker or somewhere on the webserver?
  10. Hmm, I don't quite understand your question. Do you generate them with FMSA through CWP?
  11. Have a look at YUI Autocomplete. It uses a caching algorithm to reduce server load. I use it here: http://www.clicaps.ethz.ch/ Type in a few words, e.g. "gly boyer" That it be very fast, avoid sorting of any kind.
  12. E.g. filtering? Browsing through large lists and serendipity might well make sense in certain cases, especially if a user does not exactly know which search terms to use and what exactly is in the database. See e.g. the alphabet box on http://www.eqi.ethz.ch/en/ I had learned a lot from Bruce's example. What bothered me was detailed in my previous post. We are all searchers, that's why we are here in a forum. It's here for exchange and debate.
  13. A foot may have different size, depending on country and its unit systems. See http://en.wikipedia.org/wiki/Foot_(length) There were similar problems with different length and weight measures with same name (e.g. "Elle", "Pfund", "pound", "Zentner") in European countries in the 19th century. That's why one should use SI units. Otherwise we will still experience that mars expeditions will fail their aim :
  14. I looked at Ocean's (Stephen Dolenski's) example. And I had investigated your example, including the scripts, as well (before I added my critical comments here). I fully acknowledge your's and Stephen's work. It's clear to me that these are display (and not sure, if also adequate data manipulation) techniques, that's why I spoke of VIEW above. Problems may arise if you want to process the data further and if one is in a hosted (or multi-user) environment. Or even in web-based environment, which is multi-user also. Data is in an unstored, unindexed calculation field. Sorting and finding may be slow. In a multi-user environment, each user may have a local set that is very different from the set of another user, your script or your field names, for example. These very different sets, however, are assigned to the very same key values. Normalization? Let's assume the user changes something in his local list. What happens if you would like to write back the data to the host, several of the local sets? You have to take it apart by looping through a script, assign the right key values, find in the database if the record already exists or not, and may be have to create new records. It's then you doing all the data synching, not the database. From a web perspective, the same holds true. My first thought was, that this would be a nice technique for splitting a list of keywords a user has entered into records that each hold a single keyword, by calculation only. It isn't because of the issues I raised above. Conclusion: The technique is very nice for displaying a local, temporary view of read-only data. If it must be manipulated, one has to resort to a scripted or normalized approach.
  15. No, one has to differentiate. If records of the related set are unsorted, there is no reason against using and working with a large related set in a portal. It's a view as well as the records displayed from a main table are a view. There might even be a performance advantage if one retrieves data from a portal instead the same data from the main table in PHP CWP. This was reported in the last german FM magazine.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.