Personally, I've been noodling about what a Tapestry/Clojure hybrid
might look like.

I'd advise that you take a peek at Lift, a functional web framework
built on Scala.

I have some ideas about what a component based framework would look
like in a function world (note: this would be leaving JSPs and the
like far in the dust, and moving toward a higher-order solution more
like Tapestry).  On the output side, I see the templates being
represented as nested DOM structures, and components would operate by
transforming the DOM (or a subtree of the DOM) according to their own
template and code.  I think the request handling side of things would
be a bit more traditional and action based, with routing functions
that would locate handler functions of some form, via some mix of
naming conventions and start-up registrations.

I can definitely envision areas where the (binding) construct would be
awesome for rewiring the processing of a request for specific needs,
things that in Tapestry require active filter objects contributed
statically into global pipelines.

.... but I've still got a lot of ideas for T5 to work on first :-)

Web frameworks are a tricky beast (I'm eight+ years into writing
Tapestry) there are aspects that line up beautifully with stateless
functions, but when you introduce the benefits of components, you also
bring in a lot that benefits from stateful, mutable, internal state.

On Mon, Mar 16, 2009 at 4:17 PM, BerlinBrown <[email protected]> wrote:
>
> After many years (decade) of web development, here are the things that
> I want in a framework, mostly based in clojure:
>
> What do you think and what you add.  This is ambitious and just a
> "ideas" of what I would add.  What would you want from your ideal
> framework?
>
> 1. Based on Spring Framework for middleware:
> Reason: there are years and years and years of development spent on
> spring and there are many things done right.  If I were integrating
> with any other third party libraries, I would use spring.  Spring is
> added to my framework.
>
> 2. Based on Hibernate for ORM mapping:
> Reason: the defacto standard for ORM mapping with Java.  And also used
> by NHibernate.  There is a lot of support for most popular databases.
>
> 3. Clojure/Lisp based configuration AND default XML configurations.
> This has become the standard way to configure a J2EE web application
> including spring and hibernate.  But I would like a lisp oriented
> configuration.
>
> 4. Easy mapping to URLs.  I like python's approach for URL mapping
>
> 5. Clojure based, framework based server pages AND JSPs.  I have
> always hated some aspects of JSP and ASPs, etc, etc.  They are just
> too complicated.  I would want to use Clojure code within the
> framework oriented server page and other predefined tags.
>
> 5. Lift like reusable server pages.  Lift has an interesting approach
> for resuing the same page.  E.g. you have an if-else statement within
> the page.
>
> If request == GET
> ...render this
> if request == POST
>  ...render this.
> if URL == 'abc.html'
>  .. render this.
>
> I want to embed this in my framework.  You only touch one page, but
> you get different outputs depending on the request method or URL, etc,
> etc.
>
> 6. Use of Clojure syntactic sugar -- TO BE DETERMINED.   There is the
> ability to use powerful Clojure constructs  with this framework but I
> haven't figured out how yet.
>
> 7. Better integration of CSS, Javascript, HTML.   A lot of a web
> application still resides with the client side.   I have yet to see an
> web framework that addresses client development (besides GWT).   Maybe
> something as simple as server page tags for CSS?  Javascript?
>
> 8.  Additional third party libraries:
>
> Lucene, iText, jFreeChart, optional Terracotta integration
> ----------------
>
> Other optional/additional thoughts.
>
> 9. Clear separation between back-end and front-end layers
>
>
> >
>



-- 
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to