Director shortcomings; Rev/altBrowser the solution?

[Van Esch, Stephen (Bolton)]

JB:

Thanks for the detailed reply.

>>...but I for one would suggest to keep that
project within a single development environment as much as
possible. I know it is tempting to try to catch the best of various
tools and integrate them into one single entity, but I also know
that complex projects can be difficult to maintain, and even more
difficult in an heterogenous environment...
Last but not least, passing data from the browser window to Rev
might lead to some headaches (unless this is implemented in
AltBrowser, but I don't think so).

I understand where you're coming from. We're actually trying to keep things
as simple as possible by using only XML as the content source and
repurposing it as needed (PDF, HTML etc.). Hopefully, Rev will help us
achieve this. If need be, we can probably limit the altBrowser/Rev
interactions. Again, the project has yet to be fully scoped so features can
be removed (or added) if needed.

>>This would give you full X-platform compatibility, something
you won't get with AltBrowser.

X-platform is not necessary which is great. This project will be Windows
only. We can also restrict users to IE 5.5 and greater if need be. It will
not be widely distributed and our custom software system is Windows-only.
We're lucky that we know exactly what our customers are running (even if I'm
a Mac guy).

>>Of course, handling sophisticated layouts with XHTML is tempting,
but are you sure those layouts can't be handled within Rev ?

Well, not entirely sure but from what I'm hearing, it doesn't sound like it.

>>I'm asking because I am completing a spreadsheet-like interface
for a client with Rev, and in less than 2 days I managed to get a
table with rows & columns headers, with possibility to modify
width & height of rows & cols (in a more sophisticated way than
in Excel), with portions of the table split in 4 sections across the screen
(like in Excel), automatic resizing, scrolling, etc... So having tables
with cells colours shouldn't be too difficult.

While this sounds great, for us, it might be easier to use HTML where we
can. This way, we can utilize our content on the web as well.

>>Of course, if your style include japanese, arabic or
chinese fonts, things could become somewhat less easy...

This is the real crux of the problem. The product must support multiple
languages. Without multilanguage, this project is dead in the water. Thus
far, the best solution again seems to be HTML.

>>As for parsing XML and building complex layouts on the fly, I'm
sure Rev is fast & powerful enough to handle this task.

>From what I've heard, handling XML transformations is no easy task which is
one of the reasons finding the right tool has been such a hassle (along with
the language support).

>>OTOH, if your 3D anims are pre-computed (don't need to be modified
in realtime) and only need to "react" to users' actions through hotspots
and simple operations such as rotate, translate, zoom (...), then you
probably can skip the openGL part, and simply use QT3D movies
(made in a 3D software), and embed them in your Rev stacks through
QT for Windows...

And this may be the ultimate solution. Currently, our 3D files are created
in 3D Studio Max and can be exported in a variety of formats.

>>Hope that helps,

You folks are great!

Steve

> JB:
>
> >Before answering your question, I guess a few more details
> are needed. Especially, I don't really understand why you
> need to embed a browser within a Director window ...
>
> Considering the amount of formatting required for the text and the length
of
> the text documents (scrolling will definitely be required), the only ideal
> solution I can see is HTML/XHTML. While Director and Flash do have some
text
> formatting and XML capabilities, I can't see either of them even coming
> close to what we can do with XHTML. Note that formatting includes tables
> with various cell colours, a dozen heading and paragraph styles (don't
ask),
> graphics, and captions layered on top of graphics (not embedded in the
> graphic).
>
> >...and where does the HTML file comes from ? Is the HTML code generated
on
> the fly from the XML, and is the browser window used to navigate between
> successive screens, or different frames of the Director stage?
>
> Yes the HTML will be generated on the fly from the XML file. A static page
> will be generated when the user clicks a link or selects an option on the
> Rev/Director interface (this page will automatically update when we update
> the XML file). A dynamic XHTML page based on XML data will also be
generated
> when the user does a search.
>
> The browser window will not include any controls. Links will allow users
to
> jump from one page to another (between sections, for example).
>
> A lot of the functionality will depend on what the technology can do so we
> may want the ability to pass information from the browser window to Rev or
> Director. Not sure about that, though.
>
> Thanks!
>
> Steve