 next
|
  Subject: Re: format-number in 3.1.59a
Author: Minollo I.
Date: 07 Sep 2001 02:56 PM
|
>It seems that the XSLT function format-number requires a 1.2.2 or above JRE?
That's correct.
>Since this isn't an extension functions, I would hope there would be no
>dependencies on an external JRE.
Yes, format-number does depend an external JRE; the behavior of
format-number is equivalent to what you have in Java; we have chosen this
shortcut for the time being (the assumption being that in most cases users
have at least a 1.2.x JRE installed on their machines).
>I am including an example XSL, XML, and screen shot of the error message.
>
>NOTE: There is more in the XML than necessary to create this problem, but
>I wanted to confirm that function-available() returned true for this. As
>a result, I was a bit curious that the node testing functions (e.g.
>current(), node(), ...) claimed to not be available?
current() and node() do not appear as available functions because they are
not really implemented as functions, but as pieces of the XPath processor.
I think they should be returned as available, even if I'm puzzled about why
MSXML and Xalan-J are returning current() as available and node() as not
available.
Basically the only difference between what Stylus Studio reports as
available and what MSXML and Xalan-J do, is the current() function, that we
return as not available.
We'll investigate further.
>One additional point: a nice addition would be to be able to create a
>scenario for an XML that isn't saved to disk. The option to identify a
>Project File almost seems to work, but when you open the file filter, you
>see an icon (no file name) that represents the unsaved XML but selecting
>it doesn't work. This would be a nice feature to allow for non-invasive
>proof-of-concept or testing. Although the work around is trivial :)
I see what you are saying; we will remove the untitled icons from the
project area in the Open File dialog, as you are currently not supposed to
be able to use an untitled file for anything.
Changing this in the direction you would like to see is tricky, and I don't
think it will happen anytime soon.
Thanks,
Minollo
|
|
next
|
  Subject: Re: format-number in 3.1.59a
Author: Peter Jaffe
Date: 07 Sep 2001 05:24 PM
|
On 9/7/01 2:56:40 PM, Carlo Innocenti wrote:
> Yes, format-number does depend an external JRE; the behavior of
> format-number is equivalent to what you have in Java; we
> have chosen this shortcut for the time being (the assumption
> being that in most cases users have at least a 1.2.x JRE
> installed on their machines).
I understand how implementing it this way could definitely save time (particularly when the XSLT spec defines the function as behaving like JDK1.1 DecimalFormat class). However, one of my goals is to isolate presentation layer development from application layer development, therefore installing a JRE would be an additional requirement for a "UI designer" machine.
Given 4 machines in our office, all of which have 1+ JDK/JRE installed on them (at least one of which is 1.2.2 or higher), only on 2 of them were configured such that Stylus Studio was able to automatically identified a compatible JRE (one picked up an Oracle 1.1.7, and I'm not sure what the other found).
It seems that the necessary requirements are:
1. Having a JRE bin directory in your system PATH
2. Having "Tools>Options>Application Settings>Java Virtual Machine" properly configured (which it attempts to auto-detect)
Requirement 1 is what disturbs me the most, followed closely by item 2.
I don't know what your timeline is for internalizing format-number(), but I personally cringe when a shrink wrapped product has a core function that requires "proper" installation of another toolkit. Has that been a common design pattern, and I have just uncovered the first of a few/many?
Thanks.
Pete
|
|
next
|
  Subject: RE: format-number in 3.1.59a
Author: Ivan Pedruzzi
Date: 07 Sep 2001 05:50 PM
|
Hi Peter,
having the JRE bin in the PATH is *not* a requirement, Studio use the
registry to perform the JVM auto detect. Take a look under
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime
Environment\CurrentVersion
Stylus Studio requires a compatible 1.2 JVM.
Hope this help
Ivan Pedruzzi
eXcelon Corporation
http://www.stylusstudio.com
> -----Original Message-----
> From: stylus-studio-tech Listmanager [mailto:listmanager]
> Sent: Friday, September 07, 2001 5:31 PM
> To: Recipients of 'stylus-studio-tech' suppressed
> Subject: Re: format-number in 3.1.59a
>
>
> From: "Peter Jaffe"
>
> On 9/7/01 2:56:40 PM, Carlo Innocenti wrote:
>
> > Yes, format-number does depend an external JRE; the behavior of
> > format-number is equivalent to what you have in Java; we
> have chosen
> > this shortcut for the time being (the assumption being that in most
> > cases users have at least a 1.2.x JRE installed on their machines).
>
> I understand how implementing it this way could definitely
> save time (particularly when the XSLT spec defines the
> function as behaving like JDK1.1 DecimalFormat class).
> However, one of my goals is to isolate presentation layer
> development from application layer development, therefore
> installing a JRE would be an additional requirement for a "UI
> designer" machine.
>
> Given 4 machines in our office, all of which have 1+ JDK/JRE
> installed on them (at least one of which is 1.2.2 or higher),
> only on 2 of them were configured such that Stylus Studio was
> able to automatically identified a compatible JRE (one picked
> up an Oracle 1.1.7, and I'm not sure what the other found).
>
> It seems that the necessary requirements are:
> 1. Having a JRE bin directory in your system PATH
> 2. Having "Tools>Options>Application Settings>Java
> Virtual Machine" properly configured (which it attempts to
> auto-detect)
>
> Requirement 1 is what disturbs me the most, followed closely
> by item 2.
>
> I don't know what your timeline is for internalizing
> format-number(), but I personally cringe when a shrink
> wrapped product has a core function that requires "proper"
> installation of another toolkit. Has that been a common
> design pattern, and I have just uncovered the first of a few/many?
>
> Thanks.
>
> Pete
>
>
>
> To reply: mailto:stylus-studio-tech.3633@edn.exceloncorp.com
> To start a new topic: mailto:stylus-studio-tech@edn.exceloncorp.com
> To login: http://edn.exceloncorp.com/~SSDN
>
>
|
|
next
|
Subject: Re: format-number in 3.1.59a
Author: Minollo I.
Date: 07 Sep 2001 05:55 PM
|
>...
>I don't know what your timeline is for internalizing format-number(), but
>I personally cringe when a shrink wrapped product has a core function that
>requires "proper" installation of another toolkit. Has that been a common
>design pattern, and I have just uncovered the first of a few/many?
I'm leaving to Ivan the discussion about the Java requirement issues.
About requiring "proper" installation other toolkits: Stylus Studio
requires that a JRE is properly installed on the machine where it is
running only for three particular functionality:
- format-number
- user-defined Java extension functions
- advanced Java editing, compiling and execution
If you want to debug Java extension functions (or Java applications in
general), the requirement is extended to JDK.
Stylus Studio, as any other application, relies on a "proper" installation
of several components; as we are using Microsoft technology for all the
non-internal functionality other than the ones mentioned above, in most
cases such "proper" installation is equivalent to a "Windows NT/2000/XP
proper installation".
As Java is not part of the extended concept of OS that Microsoft has (only
for the reasons we all know about), the Java requirement suddenly becomes
annoying.
We understand that; we'll do our best to improve the auto-detection
mechanism of a JVM installation; but, I will be frank with you, we don't
have plans at this point to port the format-number implementation to the
native application C++ world anytime soon.
Hope this helps,
Minollo
|
|
format-number.xml
format-number.xsl
top