xvcl-development — XVCL Development Mailing List

[XVCL] (no subject)

[<kha...@en...>]

Hello everybody,
 I have some questions about XVCL and it will be great if someone can help me 
answering them.
(I am new to XML & XVCL). 

 Here are my questions:
- What are the purposes of creating XVCL? I do realise that XVCL help us to 
build generic applications 
  which can be more flexible than usual. But what I still can't understand is 
what are the benefits of 
  such an architecture, since the code is not optimized but only distributed 
on different files (that's 
  what i think)
- How well can frames handle aspects and optimizations?
- What are the properties of this tool with respect to:
  + scalability.
  + generator runtime performance. 
 (as you know to get the executable from the ".S" file, we have to compile 
two times .S--->.java--->.class )
  + ease of debugging DSL (domain specific language) program and generator 
code.
  + readability and maintainability of DSL programs.
  + Tool maturity and stability.

Thank you for you time and consideration.

Best regards

[XVCL] Delphi HTML Component Library based on Internet Explorer

[Oleg S. <os...@ho...>]

Well, it's been almost a month since I posted a message on this mailing
list with the idea of developing a Delphi HTML Component library that
would allow component based development of user interfaces utilizing
Internet Explorer ActiveX control. The original message can be found at
http://www.geocrawler.com/archives/3/6919/2001/12/0/7254515/.
 
Despite the positive feedback received in the beginning, there was no
follow-up. Based on this situation, I'm going to add this idea to the
list of potential features for XVCL, but with resources I have, it is
not likely to be implemented, at least not for the next couple of years
:). So, if you are interested in leading the development of such
library, please raise your voice. 
 
Oleg

[XVCL] Fw: Delphi HTML Component Library based on Internet Explorer

[Oleg S. <os...@ho...>]

Hello All,

A couple of days ago I have posted the message on the mailing list asking for feedback about creating a new component
library based on XVCL (or extending XVCL if you will), that would allow to create applications using TWebBrowser control
and HTML for their user interface. Something similar to the way Outlook and Outlook Express use in their Outlook Today
view or what Windows Explorer uses to implement its Web style folder views.
If you haven't received the original message, please see the message below...

I think that overall, the feedback was very positive. By this time, I believe that more than 20 people expressed
interest in developing and/or using such a library. So it seems that now is a good time to start a discussion in a
mailing list. A couple of people asked for more information about this idea. Well, here it is.

XVCL can be used to build documents (object hierarchies) that represent HTML documents. Architecture of XVCL is based on
W3C Document Object Model, although it doesn't implement all aspects of it. But it means that XVCL documents are very
similar to HTML DOM documents that Internet Explorer and other DOM compliant browsers build internally to render HTML.
It is possible to extend XVCL in such a way that there would be a direct connection between DOM nodes in the browser's
documents and nodes in XVCL documents. Any changes to XVCL document would be reflected in the browser. More than that,
script events can be surfaced as standard Delphi component events, so that you can handle HTML document's OnClick event
in Delphi code.

In technical terms, this can be achieved by using IHTMLDocument/IHTMLElement/IHTMLDOMNode interfaces defined in
MSHTML.pas to generate HTML DOM document based on XVCL document. When a particular HTML DOM node is created, it's
pointer could serve as a "Handle" used by the library to attach events, reflect changes made to XVCL document back to
HTML DOM document, etc. This is something very similar to standard windows controls and Delphi components that
encapsulate them.

I'm not sure at this time about how exactly the changes that happen on the browser side are propagated back to XVCL
document. One way to accomplish it would be using A.P.P. (Asynchronous Pluggable Protocols) when submitting an HTML
form, but it would be able to handle other changes to HTML DOM document that aren't related to values of the controls.
May be script events can be used here as well. We will need to do more research on this one.

This is the current theory behind the idea. Now would be a good time to discuss this, resolve any potential issues and
then move on to design. So, what do you think?

A couple of words about organizational side of this. Currently, I'm the only active developer of XVCL. My time resources
are limited, as probably for anybody. At this time, I'm working on Document Designer for XVCL which is a big project on
it's own. I will be able to contribute to this new project, but I cannot lead the effort. If you feel you would be
interested in doing so - this is your opportunity to take an active role in it. Otherwise the idea will be stuck in the
list of future enhancement requests for XVCL.

I also wanted to mention that if you are interested in development of other XVCL features and not necessarily in this
particular idea - there are several directions and areas in XVCL that can be developed independently. They are currently
dormant because there is no time for me to do everything on my own. So you have opportunity to lead them. There are also
many small tasks that you could work on - check out XVCL task manager at SourceForge - there is plenty of stuff to work
on. You could be of big help even if all what you did was just use XVCL and post your feedback on this list. Please let
me know if you need more information about this.

Oleg

----- Original Message -----
From: "Oleg Sych" <os...@ho...>
To: <Del...@ya...>; <xvc...@li...>
Sent: Tuesday, December 04, 2001 1:24 PM
Subject: RFC: Delphi HTML Component Library based on Internet Explorer


Hello All,

I'm asking for your feedback about an idea of a Delphi visual component library for creating applications using HTML and
Internet Explorer browser control (TWebBrowser). Examples of existing applications using this technology are:
  * Outlook/Outlook Express (Outlook Today view)
  * Add/Remove Programs control panel applet in Windows 2000
  * Windows explorer (when using the new Web style view for folders)

All these applications are implemented using Microsoft's tools and technology and even though the programs look nice,
I'm sure the implementation mechanism is not easy to duplicate in your own apps. The Delphi library could be designed
and implemented to provide full featured support for dynamic HTML (DHTML) features including events in an easy to use
fashion similar to other Delphi component libraries.

Such a library can be created based on XVCL. For those who aren't familiar with it, in a couple of words, XVCL is a
general purpose document-oriented library, which can be used to build XML applications using Web Broker architecture or
traditional Delphi VCL. I'm currently working on Document designer that will provide design time support for XVCL
documents and will allow to create complex XML, HTML and other documents visually, using a component palette, drag&drop
and object inspector at design time. Document designer is using TWebBrowser control for representing document in "XML
view". What I realized is that it would not be a huge step from this particular feature to a full featured component
library allowing to create rich dynamic user interface based on HTML and Internet Explorer with the convenience of a
traditional Delphi component based architecture.

So the questions are:
* Would you be interested in having such an Open Source library available for you to use?
* Would you be interested in taking part in development of such library?

Any feedback would be greatly appreciated.

Thanks,
Oleg Sych
mailto:os...@ho...
http://xvcl.sourceforge.net

[XVCL] Design of NodeName and AsXXX properties

[Oleg S. <os...@ho...>]

Hi all,

There is a problem with design of NodeName and AsXXX properties of TJvxNode
class that has been on my mind for a long time. Let me give you little bit
of details to refresh memory.

NodeName property is declared in TJvxNode class as a read-only property.
Protected SetNodeName method is provided for classes that need to publish
NodeName as writeable property. The problem with this implementation is that
Delphi 5 sometimes gives an internal compiler error when compiling code
assigning NodeName of such classes as TJvxStringAttribute/Element. It's not
a huge issue, because the workaround is to rebuild the project, but it is
quite annoying sometimes.

Node value (AsXXX) properties are declared as read/write in TJvxNode class,
although the idea behind them is very similar to the idea for NodeName. Both
node name and node value properties need to provide an ability to easily
build descendant classes that have predefined node names and values. For
example TJvxHTMLInput class represents html <input> element. It's node name
should never be changed because otherwise it looses it's meaning. An example
of the same situation for node value might be a class descending from
TJvxHTMLCustomInput to represent only check boxes in html. To do that it
would need to have a fixed value of type attribute (<input
type="checkbox">). However, it is currently impossible to implement a robust
checkbox class because node value properties are declared as read/write in
the base class. So even if the class will set the type attribute to
"checkbox" nothing prevents user from accidentally changing the value to
something else.

Knowing this, it seems that it would more consistent if both NodeName and
node value properties would have the same implementation. They should either
be implemented the way NodeName is implemented currently (read-only property
with protected write method available for descendants to publish the
property as writable) or they both should be made writeable in the base
class. Personally I like the second approach better because the first
approach will mean that it is impossible to generically assign values of
attributes and elements because their value is always read-only. That will
force users to use typecasting, it gets ugly quickly. But the second
approach requires having some sort of "read-only" flags for both node name
and node value. In order to save memory space, these flags could be
implemented as items in TJvxNodeState set.

So first of all do you like the second approach?

About the second approach. There needs to be a way for component authors to
set node name and node value to be read-only after assigning initial values.
What do you think about using protected methods called FreezeNodeName and
FreezeNodeValue? Component authors would be able to call these methods in a
constructor of a component after initializing node name / node value. So by
default, node name and node value would be writable unless it is specified
otherwise by calling Freeze methods. Also what about streaming? It seems
that if name or value is frozen, it doesn't need to be streamed because it
will cause an error next time component is read from the stream and the
name/value is read-only.

Thanks,
Oleg Sych
mailto:os...@ho...
http://xvcl.sourceforge.net

Re: [XVCL] Renaming TJvxDataSource and TJvxDataField

[Oleg S. <os...@ho...>]

Hi all,

Since nobody seems to be opposed to the idea (I don't want to think of any
other reason why nobody replied :) I'm going to procede with the class
renaming. TJvxDataField class will be renamed into TJvxDataPipe and
TJvxDataSource will be renamed into TJvxDataPump. With the analogy being
that TJvxDataPipe connects a document node to it's external data source.
TJvxDataPump is something that pumps multiple portions of data through many
pipes into a composite document element. I think that these names are better
than the ones we have now, they are closer to the real meaning of the
objects, they are not ambiguous and easy to remember. So if you have any
objections, please raise your voice now.

Regards,
Oleg Sych
mailto:os...@ho...
http://xvcl.sourceforge.net

----- Original Message -----
From: Oleg Sych
To: xvc...@li...
Sent: Tuesday, March 27, 2001 12:58 PM
Subject: [XVCL] Renaming TJvxDataSource and TJvxDataField


Hi all,

I'm trying to come up with better names for classes currently named
TJvxDataSource and TJvxDataField. I feel that having names so similar to
TDataSource and TField is confusing. They also might conflict with
DataSource and DataField attributes used in HTML extention in Internet
Explorer. In TJvxDBDataSource there is a DataSource property which is also
confusing.

So what do you think about using something like TJvxDataPipe or TJvxPipeLine
or TJvxDataPipeLine for class currently named TJvxDataField. I think that
something like TJvxDataPipeLine is a better name than TJvxDataField because
it is more precisely describes what is the purpose of the class, which is
connecting a node to some source of data - database field, object property,
registry value, INI key, etc.

And what do you think about renaming TJvxDataSource into TJvxDataPipeSet or
TJvxPipeSet. On one hand it's not similar to TDataSource or TDataSet, but on
the other hand it's closer to TDataSet which is good because the class works
more like TDataSet then TDataSource, it has "Fields" and is a "cursor" of a
recordset.

Any thoughts, suggestions?

Thanks,
Oleg Sych
mailto:os...@ho...
http://xvcl.sourceforge.net

[XVCL] Renaming TJvxDataSource and TJvxDataField

[Oleg S. <os...@ho...>]

Hi all,

I'm trying to come up with better names for classes currently named =
TJvxDataSource and TJvxDataField. I feel that having names so similar to =
TDataSource and TField is confusing. They also might conflict with =
DataSource and DataField attributes used in HTML extention in Internet =
Explorer. In TJvxDBDataSource there is a DataSource property which is =
also confusing.

So what do you think about using something like TJvxDataPipe or =
TJvxPipeLine or TJvxDataPipeLine for class currently named =
TJvxDataField. I think that something like TJvxDataPipeLine is a better =
name than TJvxDataField because it is more precisely describes what is =
the purpose of the class, which is connecting a node to some source of =
data - database field, object property, registry value, INI key, etc.=20

And what do you think about renaming TJvxDataSource into TJvxDataPipeSet =
or TJvxPipeSet. On one hand it's not similar to TDataSource or TDataSet, =
but on the other hand it's closer to TDataSet which is good because the =
class works more like TDataSet then TDataSource, it has "Fields" and is =
a "cursor" of a recordset.

Any thoughts, suggestions?

Thanks,
Oleg Sych
mailto:os...@ho...
http://xvcl.sourceforge.net

[XVCL] XVCL mailing lists have been moved to SourceForge.net

[Oleg S. <os...@ho...>]

Because of numerous problems with Yahoo groups service I have decided to
move XVCL mailing lists to SourceForge.net. As of this time
xvc...@eg... and xv...@eg... mailing lists no longer
exist. They have been replaced with xvc...@li...
and xvc...@li... mailing. You can find detailed
information about new mailing lists at http://xvcl.sourceforge.net (follow
the link to Contact).

Note that all subscriptions had been moved to the new location, so you don't
need to take any action at this time.

I'm sorry about any inconveniences this may cause, on the bright side, you
will no longer receive any Yahoo ads with the messages from these lists.

Regards,
Oleg Sych
mailto:os...@ho...
http://xvcl.sourceforge.net

[XVCL] test

[Oleg S. <os...@su...>]

test

[XVCL] Test

[Oleg S. <os...@ho...>]

Test