Older blog entries for mglazer (starting at number 26)

UserDat XML stores

Location: C:\WINDOWS\Application Data\Microsoft\Internet Explorer\UserData

Reference: http://msdn.microsoft.com/library/default.asp?url=/workshop/author/behaviors/reference/behaviors/userdata.asp

Concept: The userData behavior persists information across sessions by writing to a UserData store. This provides a data structure that is more dynamic and has a greater capacity than cookies. The capacity of the UserData store depends on the security zone of the domain. The following table shows the maximum amount of UserData storage that is available for an individual document and also the total available for an entire domain, based on the security zone.

Security Zone Document Limit (KB) Domain Limit (KB) 
Local Machine 128 1024 
Intranet 512 10240 
Trusted Sites 128 1024 
Internet 128 1024 
Restricted 64 640 

The userData behavior persists data across sessions, using one UserData store for each object. The UserData store is persisted in the cache using the save and load methods. Once the UserData store has been saved, it can be reloaded even if Microsoft® Internet Explorer has been closed and reopened.

JS onload unload timer

<HTML>
<HEAD>
<TITLE>Detecting User's Time on a Page</TITLE>
<SCRIPT LANGUAGE="JavaScript">
function person_in() {
   enter=new Date();
}
function person_out() {
   exit=new Date();
   time_dif=(exit.getTime()-enter.getTime())/1000;
   time_dif=Math.round(time_dif);
   alert ("You've only been here for: " + time_dif + " seconds!!")
}
</SCRIPT>
</HEAD>
<BODY bgcolor=ffffff onLoad='person_in()' onUnLoad='person_out()'>
</BODY>
</HTML>
PHPortal 0.2.1 todos

  1. Transition XPC inline tag references.

  2. Members App Clean up.

  3. Add Default methods and Default Access Permissions.

  4. Organize Stats Date views.

  5. Standardize Format transitions Modules lib format.

I have created a userData small client-side app that uses the pop up box version 4.0 over at dynamicdrive.com.

For those that don't know the userData behaviour in MSIE allows you to create client-side XML Stores that are larger than cookies.

I comibend multipel pop up windows that have minmize, maximize, drag, and resize with the userData Behaviour methods of load existing, save as current, remove as current, with editable glyphs content areas.

Basically each pop up window can be its own WYSIWYG window with its own persistence and data store all local of course.

A simple use of this would be a networked tag board to leave a current task or top priority message(s). You can have multiple data stores but each data store only retains memory for the last saved item.

userData stores can be used to set prefences as persistent qialities to the end user. They can be used to store posted submitted userData from forms or the editable glyphs regions i mentioned above.

So what is the advantage, for me it allows for a simple local dynamic data store quality to html pages.

Editable Content WYSWIYG regions in MSIE

<SCRIPT>
function chgSpan() {
    currentState = oSpan.isContentEditable;
    newState = !currentState;
    oSpan.contentEditable = newState;
    oCurrentValue.innerText = newState;
    newState==false ? oBtn.innerText="Enable Editing" :
        oBtn.innerText="Disable Editing"
}
</SCRIPT>
</HEAD>
<BODY onload="oCurrentValue.innerText = oSpan.isContentEditable;">

Click the button to enable or disable SPAN content editing.

<BUTTON ID="oBtn" onclick="chgSpan()">Enable Editing</BUTTON>

<SPAN ID="oSpan">You can edit this text.</SPAN> SPAN can be edited: <SPAN ID="oCurrentValue"></SPAN> </BODY>

By simply adding persistence and a save this link to each editable region. You can now have a localised wiki. Without persistence the save can be uses with JSRS to save remotely withotu reloadign the page for a real wiki.

I am cleaning up the ever-growing PHPortal format core lib.

I will outsoruce the individual content type functions to individual folders and files in the adjacent lib directory so as to unclutter the existing larger than life lib and allow for easier future additions in a preformatted standardized manner.

WAP Emulator (http://www.wapsilon.com/)

WAP Query Strings:

<wml> 
<card> 
    <do type="accept"> 
        <go href="http://foo.com/stock.cgi?stk=$(stock)"/> 
    </do> 
  

Enter stock: <input name="stock" format="4A"/> </card> </wml>

WAP Post Method and Post field elements:

<wml> 
<card> 
    <do type="accept"> 
        <go href="http://foo.com/stock.cgi" method="post"> 
            <postfield name="stock" value="$(stock)"/> 
    </do> 
  

Enter stock: <input name="stock" format="4A"/> </card> </wml>

22 Jun 2002 (updated 22 Jun 2002 at 06:56 UTC) »

Responding to the advice from Malx I added a faux PATH_INFO variable in PHPortal.

This basically means anything after the file extensions are trasnformed into an array of variables.

EXAMPLE: http://dev.4arrow.com/index.xpc.text/string1/var1,val1/var2|val2/string2

PRODUCES:

$x->_URL = Array
(
   [0] => /index
   [1] => .text/string1/var1,val1/var2|val2/string2

)

$x->_PATH = Array ( [1] => string1 [var1] => val1 [var2] => val2 [4] => string2 )

All three of these characters are checked and can be used as delimters to create variables and values in urls.

$separators=array(',',':','|');

If you click the example link above view source and scroll to the end of the page and look for a XML namespace like so: <xpc:path str... />

You can also play with the link by adding and removing you own paths, delimiters, and variables to see how this works.

Added CSS and CSV content type transformation to PHPortal the CSV can use either a tab delimiter or comma separator.

As with all content type transformations they can receive and handle arrays as well as strings or singular rows, can be presented inline or as a downloadable file, can use the default or a custom template, and now can also display Object generation (after PHportal parser) or Object source (direct from data store no parsing).

17 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!