Re: Next Layer for web apps on top of CPPSERV

["Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com>]

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