[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Next Layer for web apps on top of CPPSERV
Well,
One of requirements for our project, is ability to release it as LGPL. This
automatically disqualifies XSD (although I think it's cool idea in general,
and could be usefull at least in some parts). XSD is GPL itself and
explicitly
sticks GPL onto generated code.
teng is LGPL, but it is byte-code based. I don't think I like that. Perhaps
ripping out parser would be worth it.
LibTPT is licenced under BSD-style license, which gives us lot of
flexebility.
Finally, TNTNET is also licenced under GPL, so it is question for Tommi, if
he wants to do something about it.
Tommi Mäkitalo wrote:
>Don't forget tntnet
>http://www.tntnet.org/
>
>Tommi
>
>Am Mittwoch, 4. Januar 2006 22:46 schrieb Boris Itkis:
>
>
>>Speaking of a template engine, links bellow represent
>>tree basic approaches we are to chose from, each has
>>its own straights and weaknesses:
>>
>>http://teng.sourceforge.net/ -- byte-code based
>>template engine;
>>http://codesynthesis.com/projects/xsd/ -- XML Scheme
>>to C++ classes, a lot of deps;
>>http://tazthecat.net/~isaac/libtpt/ -- self-contained
>>template language.
>>
>>IMHO, the third approach suites our purposes the best.
>>
>>To be continue...
>>
>>--Boris
>>
>>
>>--- "Ilya A. Volynets-Evenbakh"
>>
>><ilya@total-knowledge.com> wrote:
>>
>>
>>>To summarize our recent discussion about web
>>>framework and also mix in
>>>some of my thoughts that came after.
>>>
>>>What we'd like to be able to do is ability to make
>>>calls along the lines of
>>>
>>>
>>http://myserver/MyApp/Object.function?arg1=xx&arg2=yy
>>
>>
>>
>>>(alternatively arguments could be passed as POST
>>>data).
>>>
>>>This framework will also need to support
>>>serialization (for persistent
>>>storage in database, and perhaps for argument
>>>passing.
>>>
>>>It will also need to be able to validate parameters
>>>to function calls
>>>at least minimally both at compile time and at run
>>>time.
>>>
>>>Another part will be template language that can be
>>>integrated with
>>>CPPSERV. It will be compiled language - most likely
>>>translating
>>>to C++ first. Ability to bind functions and forms in
>>>template
>>>in such a way that will allow compile-time
>>>verification of correlation
>>>between templates, generated HTML, and function
>>>parameters
>>>would be nice to have.
>>>
>>>Whole application would therefore contain following
>>>parts:
>>>
>>>1. The servlet (most likely just a class derived
>>>from
>>> framework base servlet, and setting up few
>>>properties
>>> like app name)
>>>2. Description of exported classes / methods / their
>>>parameters
>>>3. Description of mappings between serializable
>>>objects
>>> and storage structure elements.
>>>4. Set of templates for UI.
>>>
>>>Export description can be used to generate wrapper
>>>classes
>>>that will be used to marshal/demarshal data and
>>>provide
>>>verification function.
>>>
>>>Now, templates are somewhat more complex issue.
>>>Main question is how to exchange data between
>>>template
>>>and calling code.
>>>One option is something like Velocity engine -
>>>templates
>>>caller explicitly binds all variables.
>>>Another idea is that each template ends up being a
>>>function
>>>and all external variables end up being function
>>>parameters.
>>>This gives us compile-time validation of coherency
>>>between
>>>data template expects and data template user
>>>supplies.
>>>
>>>Another important feature of template processor
>>>would be
>>>verifying that forms in template provide all
>>>elements needed
>>>by functions being called.
>>>
>>>I think I'll end here for now.
>>>
>>>Ilya A. Volynets-Evenbakh wrote:
>>>
>>>
>>>>So, here is the idea for next layer to build on top
>>>>
>>>>
>>>of CPPSERV.
>>>
>>>
>>>
>>>>What I want to have, is an application framework,
>>>>
>>>>
>>>which allows me to
>>>
>>>
>>>
>>>>write my objects whith their functions and _not_ to
>>>>
>>>>
>>>worry about deciding
>>>
>>>
>>>
>>>>which function to call wen.
>>>>
>>>>Let's take a standard example: on-line retail
>>>>
>>>>
>>>store.
>>>
>>>
>>>
>>>>I could define following classes: Catalogue,
>>>>
>>>>
>>>Category, Item, Order,
>>>
>>>
>>>
>>>>OrderItem, etc.
>>>>They would all have their respecitve member
>>>>
>>>>
>>>functions to do whatever
>>>
>>>
>>>
>>>>modifications
>>>>to object state they need.
>>>>
>>>>Now, as it is, I would probably write one or
>>>>
>>>>
>>>perhaps few servlets, that
>>>
>>>
>>>
>>>>would take
>>>>some sort of "action" parameter, as well as other
>>>>
>>>>
>>>data, and based on
>>>
>>>
>>>
>>>>that decide
>>>>which function to invoke for given request. I would
>>>>
>>>>
>>>need to organise and
>>>
>>>
>>>
>>>>track precisely
>>>>which objects call which functions, how they
>>>>
>>>>
>>>interact, etc.
>>>
>>>
>>>
>>>>i.e. Catalogue object could generate calls to
>>>>
>>>>
>>>Category and Item objects,
>>>
>>>
>>>
>>>>along the lines of:
>>>>
>>>><A
>>>>
>>>>
>>HREF="StoreServlet?oid=xzzy11102&action=display>Fruits</A>
>>
>>
>>
>>>><A
>>>>
>>>>
>>HREF="StoreServlet?oid=xzzy11103&action=display>Vegetables</A>
>>
>>
>>
>>>><A
>>>>
>>>>
>>HREF="StoreServlet?oid=foo1231&action=addToOrder>Apple</A>
>>
>>
>>
>>>>Now, if I ever change data that some function
>>>>
>>>>
>>>needs, i'll need to go through
>>>
>>>
>>>
>>>>all code, and make sure references to that function
>>>>
>>>>
>>>have all nessesary data.
>>>
>>>
>>>
>>>>Of course, the only way to find out if something is
>>>>
>>>>
>>>missing is through
>>>
>>>
>>>
>>>>exhaustive
>>>>testing. This is only one of maintainance problems
>>>>
>>>>
>>>- I think we could
>>>
>>>
>>>
>>>>easily come
>>>>up with many other scenarios.
>>>>
>>>>The framework I have in mind should take care of
>>>>
>>>>
>>>this at compile-time.
>>>
>>>
>>>
>>>>i.e. it should allow to generate calls to other
>>>>
>>>>
>>>objects and do parameter
>>>
>>>
>>>
>>>>checking,
>>>>either through macros, or, better through class
>>>>
>>>>
>>>templates. It should
>>>
>>>
>>>
>>>>also take
>>>>care of dispatching calls, and basic verification
>>>>
>>>>
>>>of argument validity
>>>
>>>
>>>
>>>>at run-time.
>>>>
>>>>Another aspect of any large web application is
>>>>
>>>>
>>>object persistance and object
>>>
>>>
>>>
>>>>caching. I am not sure at this point if these
>>>>
>>>>
>>>functions should be part
>>>
>>>
>>>
>>>>of same
>>>>framework, or should be separated, and be used in
>>>>
>>>>
>>>conjunction with each
>>>
>>>
>>>
>>>>other.
>>>>
>>>>
>>>--
>>>Ilya A. Volynets-Evenbakh
>>>Total Knowledge. CTO
>>>http://www.total-knowledge.com
>>>
>>>
--
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com