[Logo] Mentawai Forum - Mentawai Web Framework
  [Search] Search   [Recent Topics] Recent Topics   [Members]  Member Listing   [Groups] Back to home page 
[Register] Register / 
[Login] Login 

Forum Read-Only! Check the new site and forum here!

Messages posted by: Sven  XML
Profile for Sven -> Messages posted by Sven [24] Go to Page: 1, 2 Next 
Author Message

jamzim wrote:
Really very nice look. Great job. 


I have no idea what you are talking about

Because maintaining the search engine partymensch.de was a very time consuming issue and unfortunately the visitor count wasn't quite satisfactory, I abandoned the project about two years ago. I'm not the owner of the domain anymore and it seems someone has taken over the domain and created a blog there.
Hi all!

While developing an Ajax based application with the Mentawai framework I noticed that with the current version (1.14.1) it's not possible to cache Ajax requests on the client/browser side.

According to Steve Souders' High Performance Websites Ajax requests can and should be cached if possible.

Let's assume we have a shopping cart Ajax control. Every time the control is executed it also returns the date when the shopping cart was last modified through the Last-Modified HTTP response header. On the next request the browser sends the If-Modified-Since header along. The Ajax control can now compare these two dates and return a status code of 304 (Not Modified) if they are equal thus avoiding an unnecessary transmission of the possibly huge HTTP body.

Unfortunately in AjaxConsequence.java line 108 HttpUtils.disableCache(res); is executed which sets some HTTP headers that prevent the client from caching the Ajax requests (Cache-Control:no-cache etc). Hence the above scenario is currently not doable with Mentawai 1.14.1.

I suggest that in a future version of Mentawai the behaviour of the AjaxConsequence can be tweaked through an constructor parameter, e.g.

AjaxConsequence(String key, AjaxRenderer renderer, boolean pretty, boolean disableCaching)

By the way, what's up with Mentawai? It has been quite calm the last months, no new releases
Thank you! A lot of attention has been spent on the performance, server side as well as client side.

I'm using the JPOX ORM which utilizes a 2-level cache system for query results (one of them is an Ehcache). However a Lucene index is used to search the database which is faster and more powerful than the indices of the common open source database systems.

Regarding download speed all JavaScript files have been compressed plus the HTML responses are compressed, too. The HTML is XHTML compliant, clean and without any redundant code.
The German party search engine partymensch.de (translates into partyperson), I've been working on for the past months and which - among other open source projects - is also powered by Mentawai, has gone public yesterday.

The site probably has no use for you (the Mentawai core team) but I just wanted to let you know. Try to search for "bonn" for example to see it in action!

It has been quite calm on the Mentawai front, when is version 1.13 going to be released?
That brings me to another question which I think fits into this thread:

In my web application I want to log clicks to external sites so I've created a "Goto" servlet which is registered to the URL pattern /goto/*. The servlet reads the whole query string and sends a 303 (See Other) HTTP status code to forward to the new location.

Links now look like this: /goto/www.example.com

Since I don't want to use parameters (the links should look pretty) I don't know how to implement this feature the Mentawai way with actions. I don't want to use the PrettyURLController for the whole web application either.

Any idea?
What do you think, Sergio?
I think the ApplicationManager should be extended by this method:

Code:
public GuiceComponent guice( Class<? extends Object> klass,
     com.google.guice.Injector injector ) {
   return new GuiceComponent( klass, injector );
 }

or maybe this

Code:
public GuiceComponent ioc( String name, Class<? extends Object> klass, 
     com.google.guice.Injector injector ) { 
   GuiceComponent gc = new GuiceComponent( klass, injector );
   addComponent( name, gc );
   return gc;
 }

The GuiceComponent class should look like this:

Code:
class GuiceComponent implements Component {
   private Class<? extends Object> klass;
   private Injector injector;
 
   public GuiceComponent( Class<? extends Object> klass, Injector injector ) {
     this.klass = klass;
     this.injector = injector;
   }
   
   @Override
   public Object getInstance() throws InstantiationException {
     return injector.getInstance( klass );
   }
 }

Note: The code has not been tested! I just typed this into the forum editor

saoj wrote:

I did not know about that. So GUICE cannot instantiate by name and it needs the class as well? hummmm
 

Yes! The Injector#createInstance() method only takes a class as an argument. The Injector then creates an instance of that class (or possibly a subclass if special configuration for this class has been set before).

saoj wrote:

Maybe using the IoC like velo suggested is a way to go. It ties a name to an implementation and also has scopes. We would have a GuiceComponent, something like that.

ioc("myclass", guice(MyClass.class));

So when you do a input.getValue("myclass"), the MyClass class will be loaded by Guice.
 


That looks good!
@velo: Thank you!

saoj wrote:

Yes.

We are only missing now a GuiceInput, similar to SpringInput.

That's to request an object from the input and get it from Guice container. A GuiceFilter would setup the GuiceInput as the action input. 

I'm still thinking how to do it the "Guice" way... The problem is, with the name from the action input alone Guice doesn't know what kind of class to instantiate. So I believe we have to add another layer of configuration, something like this:

Code:
 GuiceFilter gf = new GuiceFilter()
 gf.bind( "myinput", MyClass.class );
 
 addGlobalFilter( gf );

The GuiceFilter then needs to pass this configuration to the GuiceInput... I don't quite like it but I don't see another way. Do you have a better idea?
Nice!

Is it in the beta jar?
Ok, here it is!

It works in my project but it still needs extensive testing!

Code:
package org.mentawai.core;
 
 import org.mentawai.core.Action;
 import org.mentawai.core.ActionConfig;
 import org.mentawai.core.PojoAction;
 
 import com.google.inject.Injector;
 
 /**
  * ActionConfig to tightly integrate Google Guice.
  * 
  * Use this ActionConfig if you want Guice to create your
  * Action instances and resolve all dependencies.
  * 
  * @author Sven Jacobs <sven.jacobs@web.de>
  * @version 0.1
  */
 public class GuiceActionConfig extends ActionConfig {
   private Injector injector;
   
   public GuiceActionConfig( Injector injector, Class<? extends Object> klass ) {
     super( klass );
     this.injector = injector;
   }
   
   public GuiceActionConfig( String name, Injector injector, Class<? extends Object> klass )
   {
     super( name, klass );
     this.injector = injector;
   }
   
   @Override
   public Action getAction() {
     Object instance = injector.getInstance( actionClass );
     
     if ( Action.class.isAssignableFrom( actionClass ) ) {
       return (Action)instance;
     } else {
       return new PojoAction( instance );
     }
   }
 }

EDIT: The org.mentawai.core.* imports are unnecessary. I needed them because I placed GuiceActionConfig in a different package. Feel free to remove them

saoj wrote:

I think we should create a GuiceActionConfig and a GuiceFilter, pretty much like SpringActionConfig and SpringFilter.

Feel free to help here Sven, but only if you have the time and the desire to play with it.  

Funny, I also thought that we need a GuiceActionConfig. It should have a constructor like this:

Code:
GuiceActionConfig( String, com.google.inject.Injector, Class )


I will see if I have the time to implement it. I still don't know how to implement a GuiceFilter yet, though.
By the way, I'm already using Guice functionality which goes beyond that of Mentawai. For example the Database class contains another service, the DatabaseHandler, which does the actual job.

There can be different database handlers, a JDODatabaseHandler and a MockDatabaseHandler (for testing).

Which handler actually is inserted is configured in a Module class.
Hello Sergjo,

I didn't think about thread-safety, pardon me!

I could use the SingleInstanceActionConfig but I will also think about a solution how to use Guice with the standard ActionConfig.
These are just some thoughts which came to my mind recently:

Please do not try to make Mentawai the all-in-one device suitable for every purpose!

The development of Mentawai should focus on the strength of the core framework, namely Actions, Filters and Consequences.

For other areas it should advocate and support the use of well established third party libraries (like for example Prototype for Ajax or Google Guice for dependency injection).

Recipes should explain how to use third party libraries along with Mentawai and the Mentawai core should be developed in a direction so that it works with the libraries, not against them.

I believe if Mentawai keeps being a lightweight but extensible, flexible and configurable framework it will be more successful than if it integrates and reinvents everything!

Don't be offended by my words, these are just some thoughts! I still like Mentawai
 
Profile for Sven -> Messages posted by Sven [24] Go to Page: 1, 2 Next 
Go to:   
Powered by JForum 2.1.6 © JForum Team