Struts Dialogs (was HTTP method for action-mappings)

[Don Brown <do...@gmail.com>]

About Struts Dialogs, perhaps I missed it, but how does it differ from
Beehive?  They seem to be tackling the same problem and are quite far
along.

Don

On 7/5/05, Michael Jouravlev <jm...@gmail.com> wrote:
> On 7/5/05, Don Brown <mr...@twdata.org> wrote:
> > Couldn't you create a custom DispatchAction that also takes into account the
> > request method?
> >
> > Don
> 
> Actually, this is what I did. The idea was to enhance DispatchAction
> and to build a Struts/JSP component framework on it without sliding to
> JSF or Tapestry. I think, it works out quite well because it is so
> simple.
> 
> I wrote an article on my stuff, because some people here do not see
> added value in it. Hopefully in couple of weeks or so I will be able
> to better advertise it, as I would like it to be included into Struts
> core.
> 
> Michael.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

multiple data sources

[Ziad EL KHATIB <z....@smart-up.net>]

hello everybody,

i'm working on a web application using struts. i have an access to a
database using a datasource. i've configured my datasource parameters in a
resource bundle. the problem is that i'm going to have several environments
so the datasource config will change. what's the best way to dynamise all
that ? maybe using ant but how ? 

i use the struts data-sources tag in struts-config.xml. i'll have 3 data
source for example. my question is, how can i use the right data source in
function of the environment in which i am ? i would like to that the most
proper way so that it can be dynamic and so that i don't have to change my
code before deploying froman environment to an other ... 

thanks all :-)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Struts Dialogs (was HTTP method for action-mappings)

[Rich Feit <ri...@gmail.com>]

I just want to clarify on the Beehive angle... it's a common
misperception that Beehive is all about controls, or all about web
services, or all about page flow.  It contains all three fairly
independent pieces (the conceptual link is that all use annotations in
the programming model, and the code link is that the Page Flow and Web
Services Metadata pieces both can consume controls easily).

The Page Flow piece -- basically an annotation-based extension of Struts
-- has the idea of grouping a controller and a set of view elements
(e.g., JSPs or JSF pages) into a reusable package: a "nested page
flow".  It's not exactly what you're describing, but it is much more
relevant than the Controls piece.  :)  The Beehive dist
(http://incubator.apache.org/beehive/downloads.html ) ships with a Login
nested page flow at samples/netui-samples/loginexample/loginflow.

Rich

Michael Jouravlev wrote:

>On 7/5/05, Don Brown <do...@gmail.com> wrote:
>  
>
>>About Struts Dialogs, perhaps I missed it, but how does it differ from
>>Beehive?  They seem to be tackling the same problem and are quite far
>>along.
>>
>>Don
>>    
>>
>
>Beehive is an all-ebracing system, they call a "control" anything that
>exposes some kind of resource. It is more generic. IIt uses
>annotations and metadata, external configuration, etc. It is just too
>complex. Anyway, if there is anything that I would compare Struts
>Dialogs with, it would be either JSF or portlets.
>
>Let me rewind and tell what was the original design goal. It was
>purely UI-related, and was born to life because I was unsatisfied with
>user experience of may web apps. You might see my article about
>redirect-after-post stuff on TSS. So, my library is implementation of
>this pattern in Struts. All you need is to use directly or extend
>DialogAction, and it will do everything else for you: two-phase input
>processing, managing state, saving error messages, correctly working
>with page reload and with Back button. This is the original goal and
>this is what I was selling.
>
>Here is the live demo which illustrates the idea:
>http://www.superinterface.com/strutsdialog/logincomponent.html
>The server is shared, so it may be down from time to time.
>
>The above design goal does not have anything with page controls, as
>you can see. After I implemented it, I thought that two-phase
>processing (aka redirect-after-post) allows to build componentized
>pages easily. You can just include a resource, containing HTML form.
>Then you submit input to the action defined in this form, not to the
>master page location. How to redraw the master page? Simple, the
>component redirects to it, and it reloads all it contains. The
>redirection location can be passed as parameter, but much simpler
>solution is to define it in config file. Now this became a second
>selling point: simple page controls using JSP. So much simpler than
>portlets. Much more limited too, accept input or POST, render youself
>on GET, share data via session object. But in many cases this is
>enough.
>
>Here is the second demo with the same component, embedded in JSP page:
>http://www.superinterface.com/strutsdialog/logincontrol.html
>The only changes are mappings in struts-config.xml, the Java code is
>the same as in previous example.
>
>So, better user experience and possibility to create page controls
>with only one new action class. Is it worth it? One action class (ok,
>two classes if considering SelectAction worth mentioning) versus a
>whole component framework like Beehive or portlet API. I think it is
>worth it. This can bring Struts back in the game, and boy, I want it
>to be back in the game, because I am too lazy to learn new framework
>each year.
>
>I really want people to understand what is that I am actually
>advertising ;-), so questions are welcome.
>
>Michael.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Struts Dialogs (was HTTP method for action-mappings)

[Michael Jouravlev <jm...@gmail.com>]

On 7/5/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> So are you saying you've implemented the Portlet specification, or some
> subset of it?
> 
> If not, I'm not sure I see the point.
> 
> If so, why would I choose this over an actual portlet implementation
> (which can be built on top of Struts, which is exactly what we use at
> work in the form of IBM's portal product).
> 
> I'm not asking this in a confrontational way, it's a legitimate
> question... convince me! :)
> 
> Frank

* No, I am not implementing Portlet spec or subset of it.
* I am not saying that my stuff is better than portlets.
* Originally, the whole thing was not about portlets and controls.

Have you read my answer to Don? Please do, it should explain a lot. Or
my English is really that bad? Or it is not the language, it is my
ability to explain?

I will try once again. The original reason why I started this project,
was to implement Post-redirect-Get pattern in Struts.

If this pattern does not ring a bell, this is the idea: to split one
"submit data with POST, return with page" request into two separate
requests:
* submit data with POST, update domain model, generate error messages,
then redirect to result page;
* load result page with GET.
Why? To avoid implicit resubmits and POSTDATA messages. If you do not
care for Refresh, Back and Forward buttons then this reasoning will
not convince you. But for me this is important. I hate POSTDATA
messages, I hate to answer "Yes" to "Do you want to resend POSTDATA?"
messages, I hate to log in, then to click Back button and to see the
same login form again.

Is the above clear? I'm not asking this in a confrontational way, it's
a legitimate question. :)

By the way, this pattern is official in Ruby on Rails, is official in
Wicket, can be easily configured in JSF, so I am not creating
something controversial of ground-breaking. But Struts does not have
it. Struts does not have _any_ UI support besides automatic form bean
population and dispatching of submit buttons to DispatchAction. What I
want is to add better support for stateful UI objects to Struts.

Please, try this demo once again, I know you tried, but try once more:
http://www.superinterface.com/strutsdialog/logincomponent.html
Notice, that two pages, login page and logout page are served from the
same location. This is important. You cannot log in and then go back
and see login page. Also, you can refresh any page after you submitted
an HTML form, and you won't get POSTDATA message. Also, despite how
may login attempts you made, it takes only _one_ click on Back button
to leave login component. This is what Struts Dialogs does. It also
helps to manage error messages.

After I implemented this, I realized that I could easily embed these
components into a JSP page with little efforts. Why? Because of
two-phase processing (aka redirect-after-post) that I implemented
before.

I am not saying that I implemented portlet API or created a framework
competing with portlets. I am saying, that often all that needed, is
to visually embed a component into a page. Do you really need portlet
container and portlet API to do this simple thing? No, you don't. All
you need is master JSP page and <jsp:include> directive to include a
JSP component.

Why <jsp:include> and not, for example, SSI? Because with
<jsp:include> I can include dynamic component, and I can share data
using standard servlet/JSP data structures like session.

Why two-phase components make a difference? Because user data is
submitted directly to the component instead of being submitted to the
portal container or master JSP page. This allows to get rid of portlet
container altogether _if all you need is simple inclusion of a
component_.

Please, check out the second demo with the same login component, but
this one is embedded in JSP page:
http://www.superinterface.com/strutsdialog/logincontrol.html
The only changes are mappings in struts-config.xml, the Java code is
_the same_ as in previous example. You can log in, and the master page
is redrawn, and control shows current user logged-in state. Also, the
prices on the servers are $50 lower, but this is just a sample page
;-)

Wrapping up, the goals:
* To provide better user experience and easier development of stateful
components like, for example, login dialogs.
* To develop JSP controls, which do not need any other container
besides parent JSP page.

Is it clearer, or I was not able to explain what my stuff does again ;-) ?

No, really, if I could not explain it this time, I will try again and
again, but remember that I know only this many English words :)

This is what I can do. Do you have login page in your app? I can
create a login control based on my sample, and you can just plug in it
into your app.

Actually, this is the direction I want to move. To create JSP
controls. Try to search for "asp (component or control)" using Google.
It would ask you back, 'Did you mean: "asp (component or control) " '
This is sad, but JSP has no notion of visual component or control. Ok,
so now portlet spec and JSF give us the components. But ASP had them
long ago, and ASP is no better than JSP. So, why not to create
components using pure JSP? I showed that this is possible.

If I could not explain it again, please reply, so I could think on
better wording ;-)

Michael.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Struts Dialogs (was HTTP method for action-mappings)

["Frank W. Zammetti" <fz...@omnytex.com>]

So are you saying you've implemented the Portlet specification, or some 
subset of it?

If not, I'm not sure I see the point.

If so, why would I choose this over an actual portlet implementation 
(which can be built on top of Struts, which is exactly what we use at 
work in the form of IBM's portal product).

I'm not asking this in a confrontational way, it's a legitimate 
question... convince me! :)

Frank

Michael Jouravlev wrote:
> I want to add a little to my previous email. Let's look at Portlet spec.
> 
> "A portlet fragment can be aggregated with other fragments to form a
> complete document. The content of a portlet is normally aggregated
> with the content of other portlets to form the portal page."
> 
> Yup, can do that.
> 
> "The lifecycle of a portlet is managed by the portlet container."
> 
> The lifecycle of JSP control, which can be developed with Struts
> Dialogs, is managed by whatever framework a control is based on, or by
> the control itself.
> 
> "Web clients interact with portlets via a request/response paradigm
> implemented by the portal."
> 
> In case of JSP components, web clients interact with controls via a
> request/response paradigm implemented by a control.
> 
> "Normally, users interact with content produced by portlets, for
> example by following links or submitting forms, resulting in portlet
> actions being received by the portal, which are forwarded by it to the
> portlets targeted by the user's interactions." ... "A portlet
> container receives requests from the portal to execute requests on the
> portlets hosted by it."
> 
> JSP controls receive request directly, not through a portal or portal
> container or master page or whatever. Master page does not have to
> interact with JSP controls, and controls do not have to interact with
> master page. In simple cases, they do not even know about each other.
> 
> "Portlets are not directly bound to a URL" -- JSP components are
> directly bound to a URL.
> "Web clients interact with portlets through a portal system" -- Web
> clients interact with JSP components directly
> "Portlets have a more refined request handling, action requests and
> render requests" -- Whatever that means, but JSP components have very
> refined request handling, based on two-phase request processing.
> "Portlets have predefined portlet modes and window states that
> indicate the function the portlet is performing and the amount of real
> state in the portal page" -- JSP components has three modes:
> initialization, input and rendering. Additional modes can be defined
> per component.
> "Portlets can exist many times in a portal page" -- This is what my
> stuff cannot do, because each type of Struts form bean has only one
> instance per session.
> "Portlets have access to user profile information" -- JSP controls
> have no notion of user profile. But this API can be designed ;)
> Portlets have URL rewriting functions for creating hyperlinks within
> their content, which allow portal server agnostic creation of links
> and actions in page fragments" -- With JSP controls, master page does
> not care about the links a control has.
> "Portlets can store transient data in the portlet session in two
> different scopes: the application-wide scope and the portlet private
> scope" -- Yeah, why not. Just create a key specific to a JSP control.
> "A portlet container provides persistent storage for portlet
> preferences." -- Don't have that, I admit. But then again, one can get
> only that much from API consisting of single <jsp:include>.
> 
> Michael.
> 
> --
> Dialogs for Struts
> http://struts.sourceforge.net/strutsdialogs
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 
> 
> 
> 
> 

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Struts Dialogs (was HTTP method for action-mappings)

[Michael Jouravlev <jm...@gmail.com>]

I want to add a little to my previous email. Let's look at Portlet spec.

"A portlet fragment can be aggregated with other fragments to form a
complete document. The content of a portlet is normally aggregated
with the content of other portlets to form the portal page."

Yup, can do that.

"The lifecycle of a portlet is managed by the portlet container."

The lifecycle of JSP control, which can be developed with Struts
Dialogs, is managed by whatever framework a control is based on, or by
the control itself.

"Web clients interact with portlets via a request/response paradigm
implemented by the portal."

In case of JSP components, web clients interact with controls via a
request/response paradigm implemented by a control.

"Normally, users interact with content produced by portlets, for
example by following links or submitting forms, resulting in portlet
actions being received by the portal, which are forwarded by it to the
portlets targeted by the user's interactions." ... "A portlet
container receives requests from the portal to execute requests on the
portlets hosted by it."

JSP controls receive request directly, not through a portal or portal
container or master page or whatever. Master page does not have to
interact with JSP controls, and controls do not have to interact with
master page. In simple cases, they do not even know about each other.

"Portlets are not directly bound to a URL" -- JSP components are
directly bound to a URL.
"Web clients interact with portlets through a portal system" -- Web
clients interact with JSP components directly
"Portlets have a more refined request handling, action requests and
render requests" -- Whatever that means, but JSP components have very
refined request handling, based on two-phase request processing.
"Portlets have predefined portlet modes and window states that
indicate the function the portlet is performing and the amount of real
state in the portal page" -- JSP components has three modes:
initialization, input and rendering. Additional modes can be defined
per component.
"Portlets can exist many times in a portal page" -- This is what my
stuff cannot do, because each type of Struts form bean has only one
instance per session.
"Portlets have access to user profile information" -- JSP controls
have no notion of user profile. But this API can be designed ;)
Portlets have URL rewriting functions for creating hyperlinks within
their content, which allow portal server agnostic creation of links
and actions in page fragments" -- With JSP controls, master page does
not care about the links a control has.
"Portlets can store transient data in the portlet session in two
different scopes: the application-wide scope and the portlet private
scope" -- Yeah, why not. Just create a key specific to a JSP control.
"A portlet container provides persistent storage for portlet
preferences." -- Don't have that, I admit. But then again, one can get
only that much from API consisting of single <jsp:include>.

Michael.

--
Dialogs for Struts
http://struts.sourceforge.net/strutsdialogs

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Struts Dialogs (was HTTP method for action-mappings)

[Michael Jouravlev <jm...@gmail.com>]

On 7/14/05, Ted Husted <te...@gmail.com> wrote:
> On 7/5/05, Michael Jouravlev <jm...@gmail.com> wrote:
> > I really want people to understand what is that I am actually
> > advertising ;-), so questions are welcome.
> 
> Have you done a version of the infamous Struts MailReader using Struts
> Dialog yet?
> 
> Many of us are already familiar with the MailReader, and it would be
> helpful to be able to compare, apples-to-apples, an "orthodox" Struts
> application with a Struts Dialog application :)

Ted, thanks for advice. I will do that ;) 

Michael.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Struts Dialogs (was HTTP method for action-mappings)

[Ted Husted <te...@gmail.com>]

On 7/5/05, Michael Jouravlev <jm...@gmail.com> wrote:
> I really want people to understand what is that I am actually
> advertising ;-), so questions are welcome.

Have you done a version of the infamous Struts MailReader using Struts
Dialog yet?

Many of us are already familiar with the MailReader, and it would be
helpful to be able to compare, apples-to-apples, an "orthodox" Struts
application with a Struts Dialog application :)

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Struts Dialogs (was HTTP method for action-mappings)

[Michael Jouravlev <jm...@gmail.com>]

On 7/5/05, Don Brown <do...@gmail.com> wrote:
> About Struts Dialogs, perhaps I missed it, but how does it differ from
> Beehive?  They seem to be tackling the same problem and are quite far
> along.
> 
> Don

Beehive is an all-ebracing system, they call a "control" anything that
exposes some kind of resource. It is more generic. IIt uses
annotations and metadata, external configuration, etc. It is just too
complex. Anyway, if there is anything that I would compare Struts
Dialogs with, it would be either JSF or portlets.

Let me rewind and tell what was the original design goal. It was
purely UI-related, and was born to life because I was unsatisfied with
user experience of may web apps. You might see my article about
redirect-after-post stuff on TSS. So, my library is implementation of
this pattern in Struts. All you need is to use directly or extend
DialogAction, and it will do everything else for you: two-phase input
processing, managing state, saving error messages, correctly working
with page reload and with Back button. This is the original goal and
this is what I was selling.

Here is the live demo which illustrates the idea:
http://www.superinterface.com/strutsdialog/logincomponent.html
The server is shared, so it may be down from time to time.

The above design goal does not have anything with page controls, as
you can see. After I implemented it, I thought that two-phase
processing (aka redirect-after-post) allows to build componentized
pages easily. You can just include a resource, containing HTML form.
Then you submit input to the action defined in this form, not to the
master page location. How to redraw the master page? Simple, the
component redirects to it, and it reloads all it contains. The
redirection location can be passed as parameter, but much simpler
solution is to define it in config file. Now this became a second
selling point: simple page controls using JSP. So much simpler than
portlets. Much more limited too, accept input or POST, render youself
on GET, share data via session object. But in many cases this is
enough.

Here is the second demo with the same component, embedded in JSP page:
http://www.superinterface.com/strutsdialog/logincontrol.html
The only changes are mappings in struts-config.xml, the Java code is
the same as in previous example.

So, better user experience and possibility to create page controls
with only one new action class. Is it worth it? One action class (ok,
two classes if considering SelectAction worth mentioning) versus a
whole component framework like Beehive or portlet API. I think it is
worth it. This can bring Struts back in the game, and boy, I want it
to be back in the game, because I am too lazy to learn new framework
each year.

I really want people to understand what is that I am actually
advertising ;-), so questions are welcome.

Michael.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org