The future of XUI ?

[KarlJohanKleist]

Dear fellow Adepters,

Does anybody know if PTC has publicized some sort of roadmap regarding GUI customization of Arbortext Editor?

I'm investigating the feasibility of developing a JavaScript based data binding framework for XUI, something that would be a major undertaking. Basically, I find XUI sound. But programming dynamic user interfaces using the DOM is utterly developer hostile, so I'd like to abstract that away.

Given that it's 10+ years since XUI was introduced as sequel to Galaxy/ACL Designer, and that Arbortext Editor seems to become a single-platform application, I wouldn't be too surprised if PTC had something Windows specific in their sleeve (based on XAML/WinRT, like WPF/Silverlight). I'd hate to learn about such a thing after having spent months plumbing XUI...

Thoughts, anybody?

- Merry Christmas, Happy Holidays to you all!

[ClayHelberg]

Hi Karl--

As far as I know, they are still fully behind XUI as the primary UI mechanism. Much of Editor's OOTB functionality is still implemented that way in the latest release.

If you don't like the standard AOM interfaces available in JavaScript, you should be able to adapt one of the many convenience libraries available to work with it. I know James Sulak has done some cool stuff using a variant of JQuery.

Keep in mind that you can also use ACL to drive XUI dialogs (which is, in fact, how most of the OOTB dialogs work). So if you find document manipulation to be easier in ACL than in JavaScript, you can do it that way. Or you could use a hybrid approach, where you do the easy parts in JavaScript, but call ACL functions when you have to do something complicated.

--Clay

Sent from my iPad

On Dec 21, 2011, at 7:16 AM, "Karl Johan Kleist" <karl.johan@kleist-it-consulting.de> wrote:

> Dear fellow Adepters,
>
> Does anybody know if PTC has publicized some sort of roadmap regarding GUI customization of Arbortext Editor?
>
> I'm investigating the feasibility of developing a JavaScript based data binding framework for XUI, something that would be a major undertaking. Basically, I find XUI sound. But programming dynamic user interfaces using the DOM is utterly developer hostile, so I'd like to abstract that away.
>
> Given that it's 10+ years since XUI was introduced as sequel to Galaxy/ACL Designer, and that Arbortext Editor seems to become a single-platform application, I wouldn't be too surprised if PTC had something Windows specific in their sleeve (based on XAML/WinRT, like WPF/Silverlight). I'd hate to learn about such a thing after having spent months plumbing XUI...
>
> Thoughts, anybody?
>
> - Merry Christmas, Happy Holidays to you all!
>
>
> Site Links: View post online View mailing list online Send new post via email Unsubscribe from this mailing list Manage your subscription
>
> Use of this email content is governed by the terms of service at:
>

[KarlJohanKleist]

Thanks for the tip, Clay!

James's stuff seems indeed exciting:

[berard]

I agree with what Clay said about the roadmap (at least that's what I've
heard from PTC).

I still have some issues with XUI shortcomings (eg: mouse events,
right-click menus, etc), but have been using XUI with Java for some time.

With the new year approaching, and another writing cycle for us, it was
finally time to move to 6.0. This time, everything has been implemented
using a maven build (over ant), within NetBeans (over text / eclipse). We
are also now using Spring libraries to manage RESTful service connections,
which has proven to be much faster to implement and run over our old
AXIS/WebService approach.

Regardless, our core modifications are written solely in Java, creating all
XUI on the fly, which has worked out well. There are some old, but
relevant examples up on adepters.org (eg:

[thendricks]

We have a pseudofont that was set up 10 years ago. I wasn't present at that time and those who were only have some E-mail exchanges from Xy at the time it was implemented. The one piece (I hope that is) that I am missing is determining which fonts actually make up the pseudofont. From my understanding this is a font with modifications or combinations of fonts. In our case, it appears to be the latter.

Is there an intelligent way to determine which fonts make up this pseudofont? And for those that are curious, we did an upgrade and my guess is that one of the necessary fonts for this character was not installed. Just not sure which one/s.


Trevor Hendricks<">mailto:->
Project Analyst -- Publication Systems
Technical Publications, MS: 078
e: -
Experience gracious living with Kohler

[jsulak]

Hi Karl,

If you end up trying aQuery, let me know if you run into any problems (or file an issue on Github). We've used it with several projects with good results.

-James