Re: Next Layer for web apps on top of CPPSERV

[Tommi Mäkitalo <tommi@tntnet.org>]

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