thespot4sap.com independent sap information
 

get SAP Access - pay monthly

SAP Tutorials    Online SAP Training    SAP CBT's    Forums    SAP Articles    SAP Jobs    Resumes
  SAP Access    SAP Blogs    SAP Books     Links     Vendor Directory     Submit Content    Search
Previous posts in SAPscript
Page 1840 of 5524

Making the Most of Markup

Blogger : MSDN Blogs
All posts : All posts by MSDN Blogs
Category : SAPscript
Blogged date : 2007 Jun 26

Before I started working on HDi, I was a web developer.  I found the transition to HDi pretty easy because the markup and the script were already so familiar to me.  There is, however, a very big difference with HDi markup that web developers should learn in order to make their applications more efficient.  Unlike HTML, HDi can use timing that is a subset of SMIL to modify the UI.  Those of us who come from the web world might want to shy away from this because it's unfamiliar.  We know how to animate the UI via the script and we are comfortable with that. But, if you take the time to learn markup timing, you can make your applications more efficient, your animations smoother, and your script cleaner.  

title clock vs. page clock vs. application clock

Timing elements can use the page, application, or title clocks.  In timing elements that uses the title clock, times are relative to the timeline of the title that is playing.  In timing elements that uses the application clock, times are relative to the point that the initial markup page loaded.  In timing elements that use the page clock uses, times are relative to the point that the current markup page loaded.  If your application has only one markup page, page and application clocks will behave the same way.  When using a title clock, you can go back in time to re-trigger cues.  You cannot go back in time with a page or application clock.

Because times are relative to the title timeline, timing elements that use the title clock can only be used in a title application.  Also, XPath expressions cannot be used with the title clock.  However, because this clock is tied to the title timeline, this timing element is very useful when doing a linear presentation that is tied to the movie that is playing such as the Warner Bros. IME or Universal's U Control.  If there are elements you want to appear on screen at specific points in the movie, use the title clock.  If you want to your subvideo to appear at a particular point in the movie and fade out at another point, send an event to your script using the title clock.

When using a timing element to modify style based on which element has the focus or which menu is opened, you will most likely use the application or page clock.  If you want to use an XPath expression or an XPath variable to trigger a cue, it must exist in a timing element that uses a page or application clock. 

And, something to note - your markup can contain multiple timing elements.  So, you may have a title clock on one timing element that triggers your picture-in-picture to appear on screen and specified points in the movie.  And, you may have a timing element with an application clock that manages the UI for the menu that allows the user to specify the size and position of the picture-in-picture when it does appear.

<!-- PIP should appear on screen at specific points in the movie-->

<timing clock="title">

  <par>

    <cue begin="00:00:05:00" end="00:01:20:00">

      <event name="PIP">

        <param name="display" value="show"/>

      </event>

    </cue>

    <cue begin="00:01:20:00" end="00:05:50:00">

      <event name="PIP">

        <param name="display" value="hide"/>

      </event>

    </cue>

  </par>

</timing>

 

<!-- User can control settings which specify if PIP appears at trigger points -->

<timing clock="application">

  <par>

    <cue begin="id('button_hide_pip')[state:actioned()]" end="id('button_hide_pip')[not(state:actioned())]">

      <event name="settings">

        <param name="PIF" value="off"/>

      </event>         

    </cue>

    <cue begin="id('button_show_pip')[state:actioned()]" end="id('button_show_pip')[not(state:actioned())]">

      <event name="settings">

        <param name="PIF" value="on"/>

      </event>

    </cue>

  </par>

</timing>

XPath variables

The markup is very good for modifying the style, but not so good at handling more complex logic - that's where the script comes in.  Markup communicates with the script via events - that a button has been focused or actioned or a time code has passed.  Script can communicate back by setting XPath variables - that the UI needs to be updated.

Markup sends event:

<cue begin="id('btn_custom')[state:actioned()]" e