> "Piroumian, Konstantin" wrote:
> >
> > Good day!
> >
> > <skip>
> > > > > > Built-in datatypes are numbers, arrays, dictionaries and
function
> > > > > > objects. There is a special type 'void', that has a single
possible
> > > > > > value named 'void'.
> > > > >
> > > > > What about 'strings', 'dates' and the like?
> > > >
> > > > Oh, yes, those too ;-) I forgot about them.
> > >
> > > ok, I would add 'currency', since web-oriented flow languages will
sure
> > > have to deal with strings, dates and money. And having them explicitly
> > > declared in the language might allow us to obtain 'easy' transparent
> > > handling (say, automatic money conversion)
> >
> > Hm... Money conversion can be a complex business operation depending on
> > external environment.
>
> Ok, you're right, this should probably be left to some deeper business
> logic deployed someplace (like in an EJB, WebService or external class).
>
> > >
> > > Are there any other 'first class concepts' that you guys might want to
> > > have in a flow language? IDs (as for credit-card numbers) might be
> > > another one, even if probably a concept too detailed... ok, your turn
> > > people :)
> >
> > What about EJB objects?
> > A DOM object would be also useful.
>
> Well, these things are already available as you can connect with java
> very easily (at least, this is what I want: flowmaps will be 'glue'
> between your business logic, nothing really fancy there).
Didn't know that Java could be connected to.
>
> So, probably, even Dates should be left out and delegated to the java
> classes (which are good already, so less things to write for us and less
> bugs to find!)
>
> > Speaking frankly, I've already seen something like this we are
discussing in
> > WebLogic Process Integrator (it's a Workflow Engine).
>
> Well, yes, a workflow is a special kind of 'flow', by definition, I
> would say :)
>
> > You can define your
> > workflow process using a GUI (it looks like a flow chart diagram) and
among
> > the other types you could define workflow variables of the following
types:
> > Object, EJBObject, XML.
>
> Yes, GUI driven authoring of flows is probably possible, just like it
> could be possible to provide a sort of GUI authoring process for
> sitemaps, but this is a separate concern.
The main idea was to have Object, XML and maybe EJBObject (or Business
objects and business operations) classes in the flow language.
>
> > Also, this is related more to other thread about XML-based selectors: in
> > WLPI you could define your selection logic using built-in functions and
you
> > could combine XML-based selection with other types, e.g.:
> >
> > <if test="XPath($userInput, '/confirmation/response')='yes' and
> > compareDate($startDate, $endDate)=0'" >...</if>
> > where $userInput is type of 'XML' (internally it could be a DOM object)
and
> > $startDate, $endDate are of 'java.util.Date'.
>
> I still believe that using the XML syntax to program flows is using the
> 'hammer' antipattern: 'when you have a hammer, everything looks like a
> nail'.
>
> Think about it.
I've thought about this for a very long time and could not find a better
solution to this. Another possibilty were to use Session Beans (or simple
JavaBeans to hold and control the state of the user process), but they would
have the same logic of: states, transitions, conditions and operations.
Don't know, maybe I'm too affected by the nature of the system I work on: it
is a highly interactive Billing & Customer Care system (it's web interface
part) and I am not an expert in pure publishing systems, so I don't take
into account others' needs.
For large sites like Yahoo or Amazon it would be, of course, too difficult
to manage all that state-graph, but is there any other alternative to it?
Regards,
Konstantin
P.S. If anybody is interested, then I can post a sample of a flow in XML
(both: our own and WLPI's).
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <[EMAIL PROTECTED]> Friedrich Nietzsche
> --------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
