Announcement Announcement Module
Collapse
No announcement yet.
SWF Basic question 1 Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    l would like make a conclusion of my finding Nemo , oh .. no ..is finding CRUD..hihi..

    l always start to implement CRUD first when l start an web application.Two months ago , l did it using spring MVC , and l found it is hard to implement CRUDs all inside a controller , even though l have read Spring Live , by Matt , and other thread about "MultiActionFormController" http://forum.springframework.org/viewtopic.php?t=1588 , l am still not satisfied.

    Reasons not satisfied:

    R1. For Matt case , he used parameters "delete" ,"save" , "edit" ...etc to let the CRUD controller to know which action to take . l don't like this way , becasue it will make your controller more complex , you will have a lot of if ..then ..else inside your CRUD controller....once your application logic inside the controller become complex , readability of the codes inside the controller will reduce.

    R2. For MultiActionFormController case , it need more work in xxx-servlet.xml just to let the CRUD controller know which action to take , although it is more elegance than the R1 , but it is not a standard way to do it in spring (means spring are not supported) , and you have to write the MultiActionFormController in your package , this is not elegance for me . ( l guess spring is not support it becasue of some reasons )

    R3. Sometime it is not reasonable to make all CRUDs inside a controller if you want to reuse each CRUD actions.
    http://forum.springframework.org/viewtopic.php?t=4342

    So after R1,R2,R3 , l think it is better to implement all the CRUD actions separately , using different controllers for each actions , but this will immediately cause another problem , the controller numbers and codes in xxx-servlet.xml growth very fast because each action use one controller (if you can stand it , it will be a small problem) , sometime you will get a lot parameterizeViewControllers ...hihihi .

    After l did the CRUD implementation with separate controllers for each actions , l found SWF.

    The story l search for Nemo , ah ..no ...CRUD , has been show in the previous posts in this thread , it seem more elegance to do it in SWF , because all CRUD actions are now inside a controller - publisherActions(<-- ah ... this cannot be called a controller , Keith said . Because he treated the whole flow a controller , and the "action" inside a flow is called an action or command ....hihi )

    Now my question , is SWF really better or more elegance than the separate implementation ? hm ...

    My answers :

    yes for .... codes readability ...it is more easy to read the action code (publisherActions).
    No for ...... write less code than b4 ... you have to write more for xxx-flow.xml and xxx-servlet.xml.
    No for ...... for less memory used for SWF .... you have to initialize a whole flow just for a small actions (C,R,U,D)
    yes for ..... Actions reusability ... you can reuse the Actions (publisherActions) in any other flows (but not outside the flow , becasue you have to paid the price to initialize another same action because of the disability of all MVC framework to reuse a stateless controller. http://forum.springframework.org/viewtopic.php?t=4342 , but of course Actions (like publisherActions) can only exist within flow by default ..hihi )

    l just curious that why other peoples using spring don't have the CRUD problem as mine :?:

    my conclusion:
    SWF not for such small flow , it is for more complex flow as stated many time in the docs l saw ....

    then l have an immediate question from my finding ....what is the multiAction for ? the api doc said that it is a typical use case to do CRUD .....hihi

    huh ~~ done

    moon

    Comment


    • #32
      Hmmm...

      I'm confused as to why the dispatcher servlet XML file would be more verbose with Spring Web Flow. Seriously, all it takes is a single FlowController for the whole app, and typically one MultiAction + XmlFlowFactoryBean per flow. What are you doing in your config file?

      In the future we may add a "FlowExporter" that makes one to many flow definitions available in the registry for access by a execution manager. This would require only a single bean to load all flows, instead of one FlowFactoryBean per Flow.

      MultiAction is for centralizing action logic within a single class at the method level. The actual action methods can do whatever you want.

      If you're concerned about memory usage on the server (as yes, SWF is by default stateful), consider serializing the flow out to the client using the ClientContinuationFlowExecutionStorage strategy.

      I do not understand your last point in regards to action reusability. Why is an Action not completely reusable in any flow? How does the fact that it is stateless make an impact on reusability?

      Keith

      Comment


      • #33
        I'm confused as to why the dispatcher servlet XML file would be more verbose with Spring Web Flow. Seriously, all it takes is a single FlowController for the whole app, and typically one MultiAction + XmlFlowFactoryBean per flow. What are you doing in your config file?
        for xxx-servlet.xml , almost the same amount of code , more on xxx-flow.xml.
        do not understand your last point in regards to action reusability. Why is an Action not completely reusable in any flow? How does the fact that it is stateless make an impact on reusability?
        Sorry , l miss a s in
        can only exist within flows by default
        MultiAction is for centralizing action logic within a single class at the method level. The actual action methods can do whatever you want.
        l did comparison for both CRUD implementations only. Both have cons and pros as stated above. l think CRUD are not typical use case as stated in MultiAction api docs , it is suitable for more complex use case.
        If you're concerned about memory usage on the server (as yes, SWF is by default stateful), consider serializing the flow out to the client using the ClientContinuationFlowExecutionStorage strategy.
        l just compared both CRUD implementations memory usage --> SWF more.

        when will SWF PR3 out ? ...the subflow problem still not solved ... l am waiting to test ....hihi

        moon

        Comment

        Working...
        X