Friday - The Automatic FAQ Maker
Current web convention - certainly in Western countries us to use the Latin-1 character set for rendering in the browser. This is normally configured in the first element inside the <head> element of the web page - or template. This is a typical example:
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
Note the charset=iso88589-1, denoting Latin-1 text encoding.
In NetPublish, you must set the Unicode character set (utf-8). If you don't you may find accented characters either don't display at all or render as two gibberish characters. Your templates should use this charset:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
Your website's static pages can still use whichever of the above is appropriate. If you don't use accented or special characters at all this shouldn't matter too much.
In PortWeb a form's action string was "scripts/portweb.dll?" (Win) or ".portweb.dll?" (Mac).
In NP, for both OSs you use "netpub/server.np?".
NetPublish template names always include the '.np' extension. Thus "...&template=results&...." in NP becomes "...&template=results.np&....", though of course the template itself must be re-written for NP. If you use PortWeb templates in v6, export them before upgrading your catalogues as although the PortWeb templates aren't deleted (it appears) the v7 client has no interface for accessing the data; so - export before upgrading.
Template names are case sensitive (in terms of NP handling) and spaces, symbols and accented or non-low-ASCII characters shouldn't be used. Ideally, use all lower case and underscores as a word join rather than intercapitalisation, i.e. 'results_large.np' or 'resultslarge'.np as opposed to 'results large.np' or 'resultsLarge.np'. The allowable syntax is not documented but the suggested lowercase method should be 'safe' for general use.
Templates can use relative paths. This can be useful is you with you use NPT->NP code transform to set paths - e.g. to media - in otherwise static pages. Such 'templates' cold be placed in the /pages/ section of a master template set but for organisation clarity and to avoid extra specimen assets, it can be easier to place such NPT files in the set's 'resources' folder. Any NPT files in that folder are transformed to NP files when published. To call the file as rendered HTML, use a 'base' command call and add the relative path to the template name:
'/netpub/server.np?base&site=test&catalog=catalog&template=../resources/mytest.np'
This doesn't actually change from PortWeb but the variations are worth repeating. Depending on the Form submission 'Method' used, there is a difference in the way the Command is specified when using <form> and <input> tags - as opposed to when written as a URL string. With the 'GET' Method the Form's action and command are specified separately:
<form action="netpub/server.np?" method="get">
<input type="hidden" name="find" value="">
etc.
With the POST Method the command is appended to the Action string, though an <input> element may still be required if the command itself can or must take an argument:
<form action="netpub/server.np?quickfind" method="post">
<input type="hidden" name="quickfind" value="">
etc.
The same holds true for other commands such as Add, Remove, etc. This is a subtle difference which can easily catch you out especially if you change from the GET to the POST Method during the course of a project by just amending code. Using the POST style of code and changing the Method to GET will cause your query to fail. Conversely, using the GET style if you simply change the Method to POST the code will work. So it is recommended that you use the GET-style syntax throughout the templates if you think you may need to change the form submission Method at a later date. If you get the syntax wrong you'll get this message (for a GET form, anyway):
The command parameter of the GET query string is not valid. It should be one of the following : quickfind, find, thumbnail, preview, original, add, show, remove, or archive.
The message is confusing if command verb is there - but just in the wrong place! As it happens the error message is actually wrong - it omits the 'base' command that can also be called by a GET method.
The PortWeb 'query' command is replaced by 'Find', but the function otherwise remains broadly the same except for some aspects of joins (see alos next heading below). There is also a new optional generic join parameter 'defaultjoin' - with the same 'and ' 'or' values - that can be used to set a value for all the Find query's joins instead of using individual numbered joins.
So, in NP, join parameter are numbered for the set they follow. In NP, join1 follows data triplet #1, between triplets #1 & #2; in PortWeb the same join would have been called join2 (there being no join1) as joins take the numer of the set they precede.
Thumbnail/Preview/Original have been extended from PortWeb v6.01. The NP commands are described in pages 43-51 of the NP User Guide. There are completely new commands - Archive and Base. Archive, applied to Collections, gathers all the current collection's items into a single (uncompressed) ZIP or SIT wrapper and places it in the site cache for download. Base is used to generate a page without record information but which needs to use NP API methods - the most obvious (incorrectly shown as 'search' in NP manual p43 code samples) is to generate search pages.
The new and existing commands also have some new attributes - the most useful of which is the 'all' attribute of the 'Remove' command that allows the deletion of an entire collection without specifying the actual existing collection RIDs. The NP commands and all their attributes are described - with varying accuracy <g> - in pages 43-51 of the NP User Guide.
Experimentation shows that when multiple query data triplets/joins exist, NP parses them back numbered thus: [no number], 2, 3, and so on as in value, value2, value3, etc. Also the first join is thus 'join'. The parameter names returned for second and subsequent sets are 'value2' and not 'value.2', 'value(2),' 'value[2]' or any such variation. Thus there are two sensible options for numbering parameters: param/param2/param3, or param/param/param. In the latter case it is important to make sure the parameter sets are passed in a logical order. A style of param1/param2/param3 seems to work but arguably it is better to use argument numbering as in the application, although if you need to walk the parameter, being able to iterate param+[i] can be a lot easier. If using large search pages with multiple options few of which are used in any given query, don't number parameters (think about it!) and consider very carefully how to apply the right on-screen join between the right param triplet. It's likely you'll need to either pre-process the form client side to sent a clean GET/POST call or use an interstitial ASP/PHP page to do the scripting (noting that PHP regards the word 'op' as a reserved word in some contexts making param naming even more problematic). Choose wisely!
The Thumbnail, Preview and Image commands all allow the use of width/height/aspect parameters to help set the size of the image. Be aware that use of one or more of these parameters in a call to an image asset will cause NP, on first call, to create a new image (default = JPG) of the size stated which is then stored in the cache as a not expiring asset for the duration of the site's existence. Thus don't use these parameters in the belief you're setting the image's height/width HTML attributes.
For thumbnails use record.thumbnailWidth & record.thumbnailHeight. For previews, create the screen previews at the size you'll use in NP and them set the short side's attribute to the long side times the ratio of the side lengths in the original. For the original, simply use the height/width field information from the catalogue.
This has totally changed. The old PW macros where macro names were enclosed in %quotes% has been replaced by a far more powerful system in NP. Taking a different turn NP now uses server-side code to do it's work. Techies will point out that the old macros were server side, but the difference here is that NP uses JavaScript (JS) as its server-side code delivering some pluses and minuses:
In truth you can do much more with NP than you can with PortWeb, though if you don't know JS and aren't prepared to read and understand the NP API you'll find it hard going.
Question: Changes in syntax and function from PortWeb 6 to NetPublish 7/8 [FAQ00120.htm]
Last Update:- 06 February 2007
Site and articles © Mark Anderson 2001-2007 - Visit my home page