|
»
Stripes Ignored...Again
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 | Next > |
 |
Re: Stripes Ignored...Again
by Morten Matras-3
::
Rate this Message:
I've considered open sourcing my CMS based on stripes
Hibernate - Stripes - JSP - Prototype. It handles the basic stuff like user management, website editing, multilanguage support, shop,... etc. And it can be inserted into any HTML based website in a few hours. Anyone needs something like that and I can give a demo or something. A book is absolutely essential simply because it's an important way for management to figure out whether the framework is strong enough. Regards Morten 2007/11/14, Alan Burlison <Alan.Burlison@...>: Will Hartung wrote: -- Morten Matras Udviklingschef GAMP media og Blob Communication ApS Vindegade 99-103 5000 Odense C Tlf: 61711103 E: morten@... T: 76 654321 W: www.blobcom.com E: morten@... ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: Stripes Ignored...Again
by Freddy D.
::
Rate this Message:
The following is not a sarcastic remark. I'm actually asking the question. Doesn't Wicket have 1.5 books? Apress Pro Wicket, and Manning Wicket in Action, which is not yet published? (Thus the "1.5"). How is that "several books"? Again, this is not a negative remark, just trying to get the facts straight. I'm not downing Wicket either, I think it's an excellent framework, and I really like some of the ideas behind it. Furthermore, Martijn and Eelco are doing a great job on WIA. It always comes down to that no framework is the best in every situation. Again I compare this to a car. Cars can be fast, spacious, practical, good-looking, performant, economical, and so on.. but never all of those things. So people choose their cars according to what's important for them.. Stripes is definitely underestimated. We switched from JSF to Stripes for professional development and it's been a real transformation from frustration to joy. It's kind of a paradox because what I love about Stripes is that it's relatively small and I can wrap my head around it. It is transparent and I can actually read the source code and know exactly what's going on. If it "took off" too much too fast, it might have suffered from "feature bloat" and so on. I would hope that its popularily would increase *because* of its simplicity, instead of needing 20,000 features just to impress people. It doesn't have a high learning curve and it uses standard stuff, which should be key points for companies considering it. Anyway. This is an interesting thread. Freddy -- Frederic Daoud |
|
|
Re: Stripes Ignored...Again
by nmaves
::
Rate this Message:
Just a heads up but my team is current working on using stripes for a complete redesign of a major airline carrier. This might just be the kind of cornerstone client that stripes might need.
Our current stack is JSP with some EXT-JS, JSON, AJAX Stripes iBatis IMHO this stack is the most powerful yet simplistic one that I have every worked with. As I am one of the commiters on iBatis we as a team are looking to make it more like Stripes in the area of convention over configuration. Stripes is truly a solid framework that I have had no problem convincing the rest of the development team and management to use. My plan right now it to finish up a new JPetStore (I am so sick of pets, might have to do something else) example app that uses all of these best practice solutions using the stack above. I hope to include the latest interceptors ideas that Gregg has blogged about as well. If anyone else is interested in help let me know and I can open up my SVN repo. Nathan Maves On Nov 14, 2007 11:06 AM, Freddy D. <xf2697@...> wrote:
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: Stripes Ignored...Again
by Gregg Bolinger-7
::
Rate this Message:
Something else I find interesting more so lately is that component
oriented frameworks contain, well, components. DataTables, Spinners, Sliders, ComboBoxes and all these java classes and models to support them. But now we have libraries like JQuery, Ext, YUI, etc that provide nearly the same functionality on the client utilizing ajax for server side communication. So are component oriented frameworks as relative today as they were two years ago? One year ago? What I am saying is it doesn't take a component oriented framework to have elegant widgets on the front end. I think thats often a selling point for Tapestry, JSF, Wicket, etc. At least it used to be. (I'm a big JQuery fan, FWIW). Gregg Freddy D. wrote: > mraible wrote: > >> You guys sound a lot like the Wicket guys a couple of years ago. Back >> then, they had low mailing list traffic and no books written about it. >> That's the same situation you are in. Now they have high traffic (one of >> the highest among Java web frameworks) and several books. In the past, >> they said both weren't important and now they've changed their tune. >> >> > > The following is not a sarcastic remark. I'm actually asking the question. > Doesn't Wicket have 1.5 books? Apress Pro Wicket, and Manning Wicket in > Action, which is not yet published? (Thus the "1.5"). How is that "several > books"? > > Again, this is not a negative remark, just trying to get the facts straight. > I'm not downing Wicket either, I think it's an excellent framework, and I > really like some of the ideas behind it. Furthermore, Martijn and Eelco are > doing a great job on WIA. > > It always comes down to that no framework is the best in every situation. > Again I compare this to a car. Cars can be fast, spacious, practical, > good-looking, performant, economical, and so on.. but never all of those > things. So people choose their cars according to what's important for them.. > > Stripes is definitely underestimated. We switched from JSF to Stripes for > professional development and it's been a real transformation from > frustration to joy. > > It's kind of a paradox because what I love about Stripes is that it's > relatively small and I can wrap my head around it. It is transparent and I > can actually read the source code and know exactly what's going on. If it > "took off" too much too fast, it might have suffered from "feature bloat" > and so on. I would hope that its popularily would increase *because* of its > simplicity, instead of needing 20,000 features just to impress people. It > doesn't have a high learning curve and it uses standard stuff, which should > be key points for companies considering it. > > Anyway. This is an interesting thread. > > Freddy > -- > Frederic Daoud > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: Stripes Ignored...Again
by Gregg Bolinger-7
::
Rate this Message:
That's awesome Nathan. I'm excited to learn which airline carrier.
I've always like iBatis but when I was reading the 3.0 version notes I was a big concerned about too much going into annotations. But that's a different discussion I can have with the iBatis mailing list. ;) Gregg Nathan Maves wrote: > Just a heads up but my team is current working on using stripes for a > complete redesign of a major airline carrier. This might just be the > kind of cornerstone client that stripes might need. > > Our current stack is > > JSP with some EXT-JS, JSON, AJAX > Stripes > iBatis > > IMHO this stack is the most powerful yet simplistic one that I have > every worked with. As I am one of the commiters on iBatis we as a > team are looking to make it more like Stripes in the area of > convention over configuration. Stripes is truly a solid framework that > I have had no problem convincing the rest of the development team and > management to use. > > My plan right now it to finish up a new JPetStore (I am so sick of > pets, might have to do something else) example app that uses all of > these best practice solutions using the stack above. I hope to > include the latest interceptors ideas that Gregg has blogged about as > well. > > If anyone else is interested in help let me know and I can open up my > SVN repo. > > Nathan Maves > > > On Nov 14, 2007 11:06 AM, Freddy D. <xf2697@... > <mailto:xf2697@...>> wrote: > > > > mraible wrote: > > > > You guys sound a lot like the Wicket guys a couple of years ago. > Back > > then, they had low mailing list traffic and no books written > about it. > > That's the same situation you are in. Now they have high traffic > (one of > > the highest among Java web frameworks) and several books. In the > past, > > they said both weren't important and now they've changed their tune. > > > > The following is not a sarcastic remark. I'm actually asking the > question. > Doesn't Wicket have 1.5 books? Apress Pro Wicket, and Manning > Wicket in > Action, which is not yet published? (Thus the "1.5"). How is that > "several > books"? > > Again, this is not a negative remark, just trying to get the facts > straight. > I'm not downing Wicket either, I think it's an excellent > framework, and I > really like some of the ideas behind it. Furthermore, Martijn and > Eelco are > doing a great job on WIA. > > It always comes down to that no framework is the best in every > situation. > Again I compare this to a car. Cars can be fast, spacious, practical, > good-looking, performant, economical, and so on.. but never all of > those > things. So people choose their cars according to what's important > for them.. > > Stripes is definitely underestimated. We switched from JSF to > Stripes for > professional development and it's been a real transformation from > frustration to joy. > > It's kind of a paradox because what I love about Stripes is that it's > relatively small and I can wrap my head around it. It is > transparent and I > can actually read the source code and know exactly what's going > on. If it > "took off" too much too fast, it might have suffered from "feature > bloat" > and so on. I would hope that its popularily would increase > *because* of its > simplicity, instead of needing 20,000 features just to impress > people. It > doesn't have a high learning curve and it uses standard stuff, > which should > be key points for companies considering it. > > Anyway. This is an interesting thread. > > Freddy > -- > Frederic Daoud > > -- > View this message in context: > http://www.nabble.com/Stripes-Ignored...Again-tf4800043.html#a13753068 > <http://www.nabble.com/Stripes-Ignored...Again-tf4800043.html#a13753068> > Sent from the stripes-users mailing list archive at Nabble.com > <http://Nabble.com>. > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a > browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Stripes-users mailing list > Stripes-users@... > <mailto:Stripes-users@...> > https://lists.sourceforge.net/lists/listinfo/stripes-users > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ------------------------------------------------------------------------ > > _______________________________________________ > Stripes-users mailing list > Stripes-users@... > https://lists.sourceforge.net/lists/listinfo/stripes-users > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: Stripes Ignored...Again
by transient
::
Rate this Message:
How about
*Rapid Java Web Development with Stripes Also how about creating a place on the wiki for the real world use-cases for stripes?
|
|
|
Re: Stripes Ignored...Again
by Morten Matras-3
::
Rate this Message:
Please participate in my small vote for web-framework on: http://mortenmatras.blogspot.com
Seam is taking the lead at the moment. There's also a few articles regarding google hits and job-postings for framework-trend-watching. Regards Morten Matras 2007/11/14, transient <hvyas27@...>:
-- Morten Matras Udviklingschef GAMP media og Blob Communication ApS Vindegade 99-103 5000 Odense C Tlf: 61711103 E: morten@... T: 76 654321 W: www.blobcom.com E: morten@... ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: Stripes Ignored...Again
by Gregg Bolinger-7
::
Rate this Message:
The survey question is a bit odd. Obviously no one here thinks Stripes
is the next big one. Mostly because Stripes is far to good to appeal to the idiot buzz FUD spreading corporate appealing developer population. :) Gregg Morten Matras wrote: > Please participate in my small vote for web-framework on: > http://mortenmatras.blogspot.com > > Seam is taking the lead at the moment. > > There's also a few articles regarding google hits and job-postings for > framework-trend-watching. > > Regards > > Morten Matras > > 2007/11/14, transient <hvyas27@... <mailto:hvyas27@...>>: > > > How about > > *Rapid Java Web Development with Stripes > > > > Gregg Bolinger-7 wrote: > > > > Would it make more sense to write something that was like: > > > > *Java Web Development with Stripes, [API here], and [API here].* > > > > rather than > > > > *Stripes in Action (Manning) or Beginning Stripes (APress)* > > > > Gregg > > > > Jason Sibre wrote: > >> Hear hear... > >> > >> I'd love something that went into greater depth. I'm here > because I'm > >> looking for something in Java that does for me what Quixote did > for me > >> in Python, and while it's not an exact fit, it seems to fit many of > >> the broad strokes. It even has many additional powerful > features that > >> Qx lacked (back when I was active with it - it may have evolved > since > >> then). However, I'm having a hard time ramping up, because the > >> example apps provided are not only trivial, but, well... not > exactly a > >> showcase of best practice in Stripes. The how-to's are where > the real > >> docs are for Stripes, and they're a bit light, too. > >> > >> A book for Stripes would be fantastic, and I'd even consider > >> contributing/authoring, assuming I ever get to a level with it > where > >> I'd be able to do so in a meaningful way. ;) > >> > >> Jason > >> > >> > >> On Nov 14, 2007, at 9:57 AM, Will Hartung wrote: > >> > >> > >>> On Nov 14, 2007, at 7:16 AM, Gregg Bolinger wrote: > >>> > >>> > >>>> I've got similar contacts and have been pondering such an > idea for a > >>>> while. I was going to speak with Tim, Ben, and some others > about > >>>> it to > >>>> see if they would be interested. The only problem I see with a > >>>> Stripes > >>>> book is it would be 20 pages. I'm not sure there is enough to > >>>> stripes > >>>> for an entire book. It sounds bad when you say it but its > glorious > >>>> when > >>>> you use it. ;) > >>>> > >>> Oh, I think a book on Stripes would be quite good, and I think > there > >>> can be a lot in it. > >>> > >>> Because I think the book can be not just on Stripes (which, > despite > >>> its simplicity, it has a lot of depth, all of which has > nuances that > >>> needs to be documented), but also as a benchmark for solid design, > >>> integrating a back end (DAO, JPA, Stripernate), Ajaxifying stripes > >>> (Like Remis ajax validation interceptor), plus the work of > describing > >>> a solid "Bugzooky"...something that a) does something meaningful > >>> (really meaningful) and does the "hard" things that you never > see in > >>> anything else. Like, say, a header/detail screen, a solid grid > >>> display (ajaxified even), etc. > >>> > >>> You want to bring folks to the platform, give them a really good > >>> sample application that does everything that folks need to do > so they > >>> can copy and paste their way to glory. They'll start with the > app and > >>> follow the patterns in the source code (and documented in the > book) > >>> to get their projects going fast and yet still be lightweight. > >>> > >>> Folks don't want technology, they want solutions, both > consumers and > >>> developers. Everything we KNOW that folks do EVERY DAY, we > continue > >>> to reinvent because there are all these crappy examples on the > net. > >>> > >>> A simple example, I'm here because Stripes painlessly binds and > >>> validates numbers and dates, something that is, apparently, > >>> impossible to do in Struts, or Spring MVC (at least at the time). > >>> And, with Struts, no way to easily bind lists. > >>> > >>> Obviously, that's an exageration, but none of the examples did > any of > >>> this. Spring wanted me to install some converter, like Stripes > does. > >>> But it's a DATE, who the heck doesn't use DATEs, why the heck > isn't > >>> that in the default package and you have to become an instant > expert > >>> in the framework to load a freakin' date. > >>> > >>> I've NEVER used the Type conversion feature of Stripes -- I just > >>> don't need it. > >>> > >>> So, that's what will make Stripes popular. Solve the common > cases for > >>> people, through technology and examples. Give folks a leg up. Give > >>> them a solution. > >>> > >>> Regards, > >>> > >>> Will Hartung > >>> > >>> > >>> > >>> > ------------------------------------------------------------------------- > >>> This SF.net email is sponsored by: Splunk Inc. > >>> Still grepping through log files to find problems? Stop. > >>> Now Search log events and configuration files using AJAX and a > >>> browser. > >>> Download your FREE copy of Splunk now >> > http://get.splunk.com/ <http://get.splunk.com/> > >>> _______________________________________________ > >>> Stripes-users mailing list > >>> Stripes-users@... > <mailto:Stripes-users@...> > >>> https://lists.sourceforge.net/lists/listinfo/stripes-users > >>> > >>> > >> > >> > >> > ------------------------------------------------------------------------- > > >> This SF.net email is sponsored by: Splunk Inc. > >> Still grepping through log files to find problems? Stop. > >> Now Search log events and configuration files using AJAX and a > browser. > >> Download your FREE copy of Splunk now >> http://get.splunk.com/ > >> _______________________________________________ > >> Stripes-users mailing list > >> Stripes-users@... > <mailto:Stripes-users@...> > >> https://lists.sourceforge.net/lists/listinfo/stripes-users > >> > > > > > ------------------------------------------------------------------------- > > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a > browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ > > Stripes-users mailing list > > Stripes-users@... > <mailto:Stripes-users@...> > > https://lists.sourceforge.net/lists/listinfo/stripes-users > > > > > > -- > View this message in context: > http://www.nabble.com/Stripes-Ignored...Again-tf4800043.html#a13754431 > Sent from the stripes-users mailing list archive at Nabble.com > <http://Nabble.com>. > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a > browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Stripes-users mailing list > Stripes-users@... > <mailto:Stripes-users@...> > https://lists.sourceforge.net/lists/listinfo/stripes-users > > > > > -- > Morten Matras > Udviklingschef > GAMP media og Blob Communication ApS > Vindegade 99-103 > 5000 Odense C > Tlf: 61711103 > E: morten@... <mailto:morten@...> > > T: 76 654321 > W: www.blobcom.com <http://www.blobcom.com> > E: morten@... <mailto:morten@...> > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: Stripes Ignored...Again
by Morten Matras-3
::
Rate this Message:
Stripes is good I give you that...
Morten 2007/11/14, Gregg Bolinger <gdboling.stripes@...>: The survey question is a bit odd. Obviously no one here thinks Stripes -- Morten Matras Udviklingschef GAMP media og Blob Communication ApS Vindegade 99-103 5000 Odense C Tlf: 61711103 E: morten@... T: 76 654321 W: www.blobcom.com E: morten@... ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: Stripes Ignored...Again
by mraible
::
Rate this Message:
I think this is an excellent point Gregg. I absolutely agree with you and this is something I've been telling audiences for the last couple of months at conferences. If a component-based framework's biggest feature is "components" and they're UI components - I think you can get a lot of these from widget frameworks like Dojo and YUI. Furthermore, if your widgets are in JavaScript, it's much easier to get re-use across your enterprise - regardless of whether folks are using Rails, PHP or Java to develop their web applications. Matt |
|
|
Re: Stripes Ignored...Again
by W. Hartung
::
Rate this Message:
I'd love to see your CMS system.
Regards, Will Hartung On Nov 14, 2007, at 9:20 AM, Morten Matras wrote: I've considered open sourcing my CMS based on stripes ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: Stripes Ignored...Again
by W. Hartung
::
Rate this Message:
On Nov 14, 2007, at 9:17 AM, Gregg Bolinger wrote: > Would it make more sense to write something that was like: > > *Java Web Development with Stripes, [API here], and [API here].* > > rather than > > *Stripes in Action (Manning) or Beginning Stripes (APress)* "Stripes on the Road" (with a nice picture a of wide open highway -- with stripes painted on it, of course...) Let's start at the beginning. We like to rag on Bugzooky, but here's what good 'ol BZ got right out the gate, despite it's best practice faux pas. With BZ we had all of this: Stripes setup, forms with different controls, validation, navigation, security, and file upload. All combined with a reasonable skin (far better than some I've seen. In fact I still use the core of BZs CSS and colors for my home stuff). All in one app. Seriously, it was a treasure trove of nuggets that shows people things people want to do. I hate "Blog" demos. Who the heck writes a blog app? Some do, sure, but it's doesn't show anything. It's TOO simple, and not relevant to the real world. And by the "real world" I don't mean teens and college Freshman coming off of MySpace, I'm talking about the grindstone day to day coders trying to get the back office a little bit better. BZ is such a great app because it does all of that stuff, and it does it with very little code, which makes it accessible. One of the things Microsoft did with .NET was not only did they do their decent job on a tool suite, but they also did sample applications. Again, not trivial "blogs in a minute", but pretty meaty bits like a portal app or a bulletin board kind of application. Something that coders could use as inspiration of all sorts of techniques. Here's what I would like to see. I'd love to see this somewhere, anywhere. Basically, Bugzooky 2, and 2+. Bugzooky 2 offers all of what Bugzooky has. But it offers best practice, and goes a bit farther. Features I'd like to see added include: o Header / detail screen o Dynamic Form o ValueList Pattern backed Paging lists with filtering/search o Data pickers o popup calendars o Send email o Charting o PDF report o REST web service I've tried several header / detail screens, and I'm not happy with any of them. (How do you guys do them?) Header / Detail screens on the web are just plain HARD to do. If any of you get it right, I'm eager to see it (both in grid editing and detail form editing). Dynamic Forms are, I think, one of the hardest things to do in the modern systems. Stripes (through mild hackery) does this really well, I think. It's a hard nut, but boy is it useful. Paging Lists are all the rage, with good reason. This really could be simply leveraging DisplayTag, but that's not a requirement. Kind of nice to keep the dependencies as little as possible -- faster startup for the student. Data pickers. In my day we called them "zooms". Ye Olde little magnify glass next to the field. Drop down boxes don't cut it when you have 10000 customers. I have stuff that I use, interested in what others use. Popup calendar picker -- zillion of these on the web, borrow one. But it's, again, the kind of thing EVERYONE wants and uses. Send an email. Can be trivial, HTML email complicates a bit. Solid functionality that folks need. Charts, show them how to stream content through different Resolution types. Write our own crude histogram, or leverage a library. PDF report. Everyone wants to be able to do this. This could be a Jasper integration, or whatever. REST like web service. With the friendly URL support, this is a cakewalk piece of code, and popular today. But I want BZ 2 to do all of that, using classic action framework techniques. Things like the Calendars are pure javascript, but the data pickers are a bit of a mix. The rest can easily be just JSPs and actions. (of course, I'd throw in some JSP Tag FIle action too, being as I'm just a big fan...) Now, I don't know what kind of work you folks do, but that list, to me, satisfies a high 80-90% mark of functionality in most any back office application. Save for the calendar, few of these are "components" (the paged list perhaps), but they're higher level blocks that show how the whole app is structured, and how someone can easily replicate what they see and just change out the DAO and actions. Now, take BZ 2. Take the data model, take the business logic, redo the action bits a little and make it in to a "pure" Ajax "RIA". Probably 75% of the code is taken from BZ 2, and the front end is written using Prototype and ext-js or whatever. Same functionality, different front end -- still Stripes. Why do this? Obviously because we can. Action frameworks are particularly well suited to back up the JS Component toolkits we have today. Convert the actions in to more REST like behaviors (you know this will be mostly minor work), and front them with a JS toolkit. Same code, different app. Shows how Stripes works great with its feet in either pond. Shows how to can go with what you know and still learn the new and flashy, and still keep your code investment. I think BZ 2 can be spec'd to include all of these features, without making it contrived. Rather, we just round it out. Write that, twice, and you have the making of a book, or a real nice web site. You also have a decent in house tracking app that's pre documented and ready to be used as is or hammered to fit leveraging all of the technique used to build it. It's also chock full pieces that can readily be integrated and used to create new from scratch applications. And best of all, it gives new users a skeleton structure to hang their code on. Lets them focus on their application. Because the best way to learn a framework is to simply use it. But when the framework gets in its own way, you're no longer using it, you're decoding it. Better to write your own application, writing code YOU are interested in and follow some ready made examples to of where to put your logic. Then you learn the framework, essentially, through osmosis. Just by wading around in it building your app, you pick up the framework. I think this would be a great asset to the Java community in general, and the Stripes community in particular. And I don't think it is an arduous task. I do, however, have ZERO time right now to work on something like this. And, I think, Gregg is sorta kinda working on something like this, but I don't know how far he went with it. But I'd like to see this. I'd like to see a book that puts these two applications together and offers source code, talks about why they do what they do. I'd love to buy that book. (Hell, I'd love to see this written for Swing too.) I'd love to write this book. A book like this, IMHO, has been missing from the Java community since forever. Regards, Will Hartung ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: Stripes Ignored...Again
by Jeppe Cramon
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hi I agree with Matt. We need popularity to
write a book (which I think would be a good thing to write). So let’s start writing blog entries
on Stripes. I’ve presented Stripes quite a few times and everyone has
been impressed, but the question always ends up on, are anyone using it? To make people interested, let’s
write some articles, presenting why Stripes is so much better than the
alternatives (I’ve lived the pain of Spring MVC and Struts 1.x, so I have
some background there). Make people interested. Get the blogs/articles
on infoq.com and theserverside.com If enough of us write articles, this it is
bound to gather interest. Especially if we coordinate our writings, so we don’t
all compare it to the same framework or all write about the same specific
features (we only have limited spare time and there’s enough to write
about). /Jeppe From:
stripes-users-bounces@...
[mailto:stripes-users-bounces@...] On Behalf Of Lukas Vlcek Hi, On Nov 14, 2007 4:57 PM, Will Hartung <redrocks@...> wrote:
Oh, I think a book on Stripes would be quite good, and I think there
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: Stripes Ignored...Again
by Jeppe Cramon
::
Rate this Message:
Hi Gregg
You're on to something regarding component frameworks and Ajax applications. The better the JavaScript frameworks become, the less value I see in standard Java Component Web Frameworks, where you have a "silly" and hard to maintain mix between component rendering and component functionality. Much of what you used to code in the server side components can now live and execute on the client, like the rendering and sorting features of a table. So what's left on the server side when all the components live and is written in a different language (JavaScript) apart from your business logic? When everything else is in JavaScript, why not have most (if not all) the navigation logic in JavaScript as well. The JavaScript Framework of your choice is truly your application framework. I think GWT is onto something right (haven't used it for any real life projects yet, so this is just an assumption). Most like Java because of what it buys you because of static typing (which buys us refactoring, nice code navigation, find references, implementations of, type hierarchy, code completion, etc.) and the immense number of 3rd party frameworks that can help us speed things up (like Spring Framework, Hibernate). JavaScript is dynamically typed and offers a whole lot of other stuff and it mixes very well with our component rendering (in HTML). With GWT and its component wrappers, we get to code Java and use JavaScript behind the scenes (I'm still wondering how well it works out when it all fails and you have to look through the generated JavaScript, when all you ever wanted was to avoid JavaScript) and you get to provide your server side services in Java too (you don't have to think about JSON, XML, etc.). So to me, you either love Java and for all sakes want to keep coding in Java alone and choose GWT, or you love to mix and match Java and JavaScript and choose a good and simple framework with superb data binding and extensibility like Stripes and mix it with what ever suits you on the client side (like jQuery which to me seems like a better mix day by day now that it has UI components). By choosing Stripes (a request based framework) for an Ajax application you more and more also choose that your components in fact are JavaScript components. You might have server side wrappers/helpers for your JavaScript components rendering + some templates, but that's about it. /Jeppe > -----Original Message----- > From: stripes-users-bounces@... [mailto:stripes-users- > bounces@...] On Behalf Of Gregg Bolinger > Sent: 14. november 2007 19:20 > To: Stripes Users List > Subject: Re: [Stripes-users] Stripes Ignored...Again > > Something else I find interesting more so lately is that component > oriented frameworks contain, well, components. DataTables, Spinners, > Sliders, ComboBoxes and all these java classes and models to support > them. But now we have libraries like JQuery, Ext, YUI, etc that provide > nearly the same functionality on the client utilizing ajax for server > side communication. > > So are component oriented frameworks as relative today as they were two > years ago? One year ago? What I am saying is it doesn't take a > component oriented framework to have elegant widgets on the front end. > I think thats often a selling point for Tapestry, JSF, Wicket, etc. At > least it used to be. > > (I'm a big JQuery fan, FWIW). > > Gregg > > Freddy D. wrote: > > mraible wrote: > > > >> You guys sound a lot like the Wicket guys a couple of years ago. Back > >> then, they had low mailing list traffic and no books written about it. > >> That's the same situation you are in. Now they have high traffic (one > of > >> the highest among Java web frameworks) and several books. In the past, > >> they said both weren't important and now they've changed their tune. > >> > >> > > > > The following is not a sarcastic remark. I'm actually asking the > question. > > Doesn't Wicket have 1.5 books? Apress Pro Wicket, and Manning Wicket in > > Action, which is not yet published? (Thus the "1.5"). How is that > "several > > books"? > > > > Again, this is not a negative remark, just trying to get the facts > straight. > > I'm not downing Wicket either, I think it's an excellent framework, and > I > > really like some of the ideas behind it. Furthermore, Martijn and Eelco > are > > doing a great job on WIA. > > > > It always comes down to that no framework is the best in every > situation. > > Again I compare this to a car. Cars can be fast, spacious, practical, > > good-looking, performant, economical, and so on.. but never all of those > > things. So people choose their cars according to what's important for > them.. > > > > Stripes is definitely underestimated. We switched from JSF to Stripes > for > > professional development and it's been a real transformation from > > frustration to joy. > > > > It's kind of a paradox because what I love about Stripes is that it's > > relatively small and I can wrap my head around it. It is transparent and > I > > can actually read the source code and know exactly what's going on. If > it > > "took off" too much too fast, it might have suffered from "feature > bloat" > > and so on. I would hope that its popularily would increase *because* of > its > > simplicity, instead of needing 20,000 features just to impress people. > It > > doesn't have a high learning curve and it uses standard stuff, which > should > > be key points for companies considering it. > > > > Anyway. This is an interesting thread. > > > > Freddy > > -- > > Frederic Daoud > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Stripes-users mailing list > Stripes-users@... > https://lists.sourceforge.net/lists/listinfo/stripes-users > > __________ NOD32 2658 (20071114) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: Stripes Ignored...Again
by bfoo
::
Rate this Message:
So lets start with a marketing slogan: Stripes (Not yet rated)
;) First I think, Stripes should not try to compete with all the other huge monolithic frameworks. So on the one hand I'm satisfied with Raible's blog entry. On the other hand, from time to time, Raible can give his readers a little overview over products not having the capability of hype (yet) and having the value to be mentioned. Second, Stripes does not require a book yet. First of all, Stripes needs a better website, which correlates with the lightweight and extensible character of Stripes. Think about it, when you open the website of Ruby on Rails (like http://www.rubyonrails.org/screencasts). Stripes should not try to convince developers not to use Struts or Seam etc. Most of the developers out there do know Struts and if they hit the website, they are already interested in another / a better approach to things. Only tell them what Stripes can do and tell that short and precise (I do not mean the documentation). It's all about marketing. It needs to get to the agile developers which have the freedom to choose whether to take the lightweight framework to get things done or to download a 100 Megabyte Seam release. And not those, who do not have the freedom because of political decissions in their enterprise or the hype-followers. If the agile developer (target: freelancers) is satisfied with Stripes, he will spread the word, as I do! Regards, Robert mraible schrieb: > I agree that Stripes is an excellent framework. However, I also believe it > needs better marketing. It's virtually unknown because there aren't that > many articles, books or blogs posted about it. I've tried to sell it to > companies on my last two projects and it's often shunned because no one has > heard of it. Also, there's no "poster child" application that proves it's a > great framework for a large-scale deployment. > > I definitely like it and would prefer to use it when developing an > application that needs a request-based framework. However, it's been very > difficult to convince companies that it's a good idea. > > More and more, I'm seeing Spring MVC chosen by companies because they are > already using Spring in the middle-tier or backend. It's unfortunate, but I > can also understand the justification behind it. > > Matt > > > Gregg Bolinger-7 wrote: >> I know Stripes is young but its really solid. However, it doesn't >> hardly get a blip on the "which framework" radar. I think this is >> primarily because it's not a component framework. (thanks God). >> Example, it was left off Matt Raible's latest blog entry: >> >> http://raibledesigns.com/rd/entry/comparing_web_frameworks_time_for >> >> I thought about leaving a comment but I don't really see the point. I'm >> content to keep using it regardless of mass appeal. I just hope that >> there are enough folks that feel the same way so that it keeps being >> developed. What I don't understand is why other developers think that >> convoluted monolithic beasts like Seam and Wicket are supperior? And >> what's up with GWT being on that list as a Web Framework? It's a client >> side rendering engine. Same with Flex and OpenLazslo. You can't >> develop anything without server side code which neither frameworks >> provide. Oh well. >> >> Gregg >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. >> Still grepping through log files to find problems? Stop. >> Now Search log events and configuration files using AJAX and a browser. >> Download your FREE copy of Splunk now >> http://get.splunk.com/ >> _______________________________________________ >> Stripes-users mailing list >> Stripes-users@... >> https://lists.sourceforge.net/lists/listinfo/stripes-users >> >> > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: Stripes Ignored...Again
by Gregg Bolinger-7
::
Rate this Message:
Whew! You wrote a book just now Will. :) You make some good points and
I'd like to try and hit most of them with my thoughts as well. But first my initial thoughts. I've been around quite a few folks writing tech books. I've been a technical review for some and am actually tech reviewing the 2nd edition of beginning python from APress right now. So I get to see all those cool little editor notes in the margins from Word's track changes feature. Tech authors don't make money from writing books. Publishers make money. Sure, authors get a kickback but you can't live off of it. The real focus of a tech book is being as relevant as possible in the market RIGHT NOW. All of Will's ideas are great but they won't make it into a book because its too broad. The topics are too broad and some don't really deal with Stripes at all. I contacted the lead Java editor at APress just to scratch his ear a bit. He's asking for information and motivation. I'm holding off speaking with him further until we all decide what needs/wants to be done and who is going to do it. That's not to say APress is the publisher of choice. I've also got contacts at Manning and OReily. Choosing a puiblisher is important because if you choose the wrong one then you will write the wrong book. There's also the option of self publishing. If you consider you aren't going to make much money anyway then self publishing gives you a lot more freedom in what you want to talk about. Kent Tong's Enjoying Web Development with Tapestry is a good example (http://www.agileskills2.org/EWDT/). The first 4 chapters are free and then you buy a yearly subscription for the rest of the book and get all the updates a long the way. I just throw these things out there to give everyone a heads up. Its easy to say "let's write a book" but getting it done is a lot of very hard work. All nighters, publishers, editors, manuscripts, choices. It's really hard. I think the idea of a new web site for Stripes is good. I think the idea of more bloggers on Stripes is good. I think the idea of a more open wiki with a lot of contributions is a really good idea and the wiki could really start outlining the book if we wanted. Now for a few comments on Will's suggestions. Features I'd like to see added include: o Header / detail screen o Dynamic Form o ValueList Pattern backed Paging lists with filtering/search o Data pickers o popup calendars o Send email o Charting o PDF report o REST web service *I've tried several header / detail screens, and I'm not happy with any of them. (How do you guys do them?) Header / Detail screens on the web are just plain HARD to do. If any of you get it right, I'm eager to see it (both in grid editing and detail form editing).* I'm not sure I understand what a header / details screen is. *Dynamic Forms are, I think, one of the hardest things to do in the modern systems. Stripes (through mild hackery) does this really well, I think. It's a hard nut, but boy is it useful.* I'm not sure how Bugzooka would benfit from such a thing and I'm not sure showing "mild hackery" in a book is a good idea. I also don't think 90% of the readers would really care about dynamic forms. This seems more like a really good wiki entry. *Paging Lists are all the rage, with good reason. This really could be simply leveraging DisplayTag, but that's not a requirement. Kind of nice to keep the dependencies as little as possible -- faster startup for the student.* I've done this too many times to count and yes it would make a good addition for discussion in a book. *Data pickers. In my day we called them "zooms". Ye Olde little magnify glass next to the field. Drop down boxes don't cut it when you have 10000 customers. I have stuff that I use, interested in what others use.* Not sure what these are either. :) *Popup calendar picker -- zillion of these on the web, borrow one. But it's, again, the kind of thing EVERYONE wants and uses.* Sure, these would be good in Bugzooka. JQuery.UI has a really nice one. However, I'm not sure how this would fit in a book about Stripes sense there's nothing Stripes about it. *Send an email. Can be trivial, HTML email complicates a bit. Solid functionality that folks need.* Again, how is this about Stripes? *Charts, show them how to stream content through different Resolution types. Write our own crude histogram, or leverage a library.* Bugzooka, yes, book, not so much. *PDF report. Everyone wants to be able to do this. This could be a Jasper integration, or whatever.* Bugzooka, yes, book, not so much. *REST like web service. With the friendly URL support, this is a cakewalk piece of code, and popular today.* Possible this could be a good book topic. Will Hartung wrote: > On Nov 14, 2007, at 9:17 AM, Gregg Bolinger wrote: > > >> Would it make more sense to write something that was like: >> >> *Java Web Development with Stripes, [API here], and [API here].* >> >> rather than >> >> *Stripes in Action (Manning) or Beginning Stripes (APress)* >> > > "Stripes on the Road" (with a nice picture a of wide open highway -- > with stripes painted on it, of course...) > > Let's start at the beginning. > > We like to rag on Bugzooky, but here's what good 'ol BZ got right out > the gate, despite it's best practice faux pas. > > With BZ we had all of this: Stripes setup, forms with different > controls, validation, navigation, security, and file upload. All > combined with a reasonable skin (far better than some I've seen. In > fact I still use the core of BZs CSS and colors for my home stuff). > All in one app. > > Seriously, it was a treasure trove of nuggets that shows people > things people want to do. > > I hate "Blog" demos. Who the heck writes a blog app? Some do, sure, > but it's doesn't show anything. It's TOO simple, and not relevant to > the real world. And by the "real world" I don't mean teens and > college Freshman coming off of MySpace, I'm talking about the > grindstone day to day coders trying to get the back office a little > bit better. > > BZ is such a great app because it does all of that stuff, and it does > it with very little code, which makes it accessible. > > One of the things Microsoft did with .NET was not only did they do > their decent job on a tool suite, but they also did sample > applications. Again, not trivial "blogs in a minute", but pretty > meaty bits like a portal app or a bulletin board kind of application. > Something that coders could use as inspiration of all sorts of > techniques. > > Here's what I would like to see. I'd love to see this somewhere, > anywhere. > > Basically, Bugzooky 2, and 2+. > > Bugzooky 2 offers all of what Bugzooky has. But it offers best > practice, and goes a bit farther. > > Features I'd like to see added include: > > o Header / detail screen > o Dynamic Form > o ValueList Pattern backed Paging lists with filtering/search > o Data pickers > o popup calendars > o Send email > o Charting > o PDF report > o REST web service > > I've tried several header / detail screens, and I'm not happy with > any of them. (How do you guys do them?) Header / Detail screens on > the web are just plain HARD to do. If any of you get it right, I'm > eager to see it (both in grid editing and detail form editing). > > Dynamic Forms are, I think, one of the hardest things to do in the > modern systems. Stripes (through mild hackery) does this really well, > I think. It's a hard nut, but boy is it useful. > > Paging Lists are all the rage, with good reason. This really could be > simply leveraging DisplayTag, but that's not a requirement. Kind of > nice to keep the dependencies as little as possible -- faster startup > for the student. > > Data pickers. In my day we called them "zooms". Ye Olde little > magnify glass next to the field. Drop down boxes don't cut it when > you have 10000 customers. I have stuff that I use, interested in what > others use. > > Popup calendar picker -- zillion of these on the web, borrow one. But > it's, again, the kind of thing EVERYONE wants and uses. > > Send an email. Can be trivial, HTML email complicates a bit. Solid > functionality that folks need. > > Charts, show them how to stream content through different Resolution > types. Write our own crude histogram, or leverage a library. > > PDF report. Everyone wants to be able to do this. This could be a > Jasper integration, or whatever. > > REST like web service. With the friendly URL support, this is a > cakewalk piece of code, and popular today. > > But I want BZ 2 to do all of that, using classic action framework > techniques. Things like the Calendars are pure javascript, but the > data pickers are a bit of a mix. The rest can easily be just JSPs and > actions. (of course, I'd throw in some JSP Tag FIle action too, being > as I'm just a big fan...) > > Now, I don't know what kind of work you folks do, but that list, to > me, satisfies a high 80-90% mark of functionality in most any back > office application. Save for the calendar, few of these are > "components" (the paged list perhaps), but they're higher level > blocks that show how the whole app is structured, and how someone can > easily replicate what they see and just change out the DAO and actions. > > Now, take BZ 2. Take the data model, take the business logic, redo > the action bits a little and make it in to a "pure" Ajax "RIA". > > Probably 75% of the code is taken from BZ 2, and the front end is > written using Prototype and ext-js or whatever. Same functionality, > different front end -- still Stripes. > > Why do this? Obviously because we can. Action frameworks are > particularly well suited to back up the JS Component toolkits we have > today. Convert the actions in to more REST like behaviors (you know > this will be mostly minor work), and front them with a JS toolkit. > > Same code, different app. Shows how Stripes works great with its feet > in either pond. Shows how to can go with what you know and still > learn the new and flashy, and still keep your code investment. > > I think BZ 2 can be spec'd to include all of these features, without > making it contrived. Rather, we just round it out. > > Write that, twice, and you have the making of a book, or a real nice > web site. You also have a decent in house tracking app that's pre > documented and ready to be used as is or hammered to fit leveraging > all of the technique used to build it. It's also chock full pieces > that can readily be integrated and used to create new from scratch > applications. > > And best of all, it gives new users a skeleton structure to hang > their code on. Lets them focus on their application. Because the best > way to learn a framework is to simply use it. But when the framework > gets in its own way, you're no longer using it, you're decoding it. > Better to write your own application, writing code YOU are interested > in and follow some ready made examples to of where to put your logic. > Then you learn the framework, essentially, through osmosis. Just by > wading around in it building your app, you pick up the framework. > > I think this would be a great asset to the Java community in general, > and the Stripes community in particular. And I don't think it is an > arduous task. > > I do, however, have ZERO time right now to work on something like > this. And, I think, Gregg is sorta kinda working on something like > this, but I don't know how far he went with it. > > But I'd like to see this. I'd like to see a book that puts these two > applications together and offers source code, talks about why they do > what they do. I'd love to buy that book. (Hell, I'd love to see this > written for Swing too.) I'd love to write this book. A book like > this, IMHO, has been missing from the Java community since forever. > > Regards, > > Will Hartung > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Stripes-users mailing list > Stripes-users@... > https://lists.sourceforge.net/lists/listinfo/stripes-users > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: Stripes Ignored...Again
by W. Hartung
::
Rate this Message:
Oh, I understand enough about the book writing process to know I don't really want to understand the book writing process :-). But I'm not fixated on the medium...I just want the content...
> I'm not sure I understand what a header / details screen is. Really? What different worlds we live in. Maybe it's a vocabulary thing... But, I'll explain. The classic example is ye olde Order Entry. Most systems break orders in to two pieces: the order itself, and the items in the order. The order is the "header" and the items are the "detail. The order captures the date, the customer, perhaps order terms, etc. The items list each item on the order: 1 vcr, 1 MP3 player, 4 blank video tapes. From a "shopping cart" point of view, you, as the user, are pretty much never presented with an order as an order and it's items, save in the summary at the end. Most shopping carts have you pick the items first, then fill out the order at the end. In the back office, though, typically you get a paper order that needs to be keyed in. The order is entered first, then each item is added. You almost always need a way easily add and delete items from the order. Most UIs in the past would let you simply add lines on the screen as you add line items. Others you might pop up a screen (because the data is too much for a single line, and the line is simply a summary). That whole workflow is a pain on the web with the mix of client and server side state, adding of dynamic controls to the web page (if you're adding a row, say), etc. > I'm not sure how Bugzooka would benfit from such a thing and I'm not > sure showing "mild hackery" in a book is a good idea. I also don't > think 90% of the readers would really care about dynamic forms. This > seems more like a really good wiki entry. Well, if you want to add user configurable meta data to a bug entry, you would need some kind of dynamic form mechanism. And it's nice if that extra data is typed (strings, numbers, dates). You would configure the extra fields in the back end and the system would add them to the screens automatically. The "hackery" is basically routing around the error display mechanism to work properly with the dynamic form fields and getting meaningful error messages. It's mostly done by gaming the automatic binding mechanisms that Stripes uses for maps and lists, plus data conversion. >> *Data pickers. In my day we called them "zooms". Ye Olde little >> magnify glass next to the field. Drop down boxes don't cut it when >> you have 10000 customers. I have stuff that I use, interested in what >> others use.* > Not sure what these are either. :) Fascinating. Well, let's go back to the order entry scenario. At a minimum you need to be able to enter the Customer code and the item codes in to the fields. How do you know what code to enter? Most systems don't use "Acme Explosives Manufacturing" as a primary key, rather they use 132524 or some other meaningless code. So, at data entry time, how do you look those values up? For small lists, web forms use drop down boxes. But those go from handy to really really horrible at around 10 entries (IMHO). What I'm used to is being able to click a button (magnify glass) which pulls up a form that I can use to query for the data at hand. So, say, the customer table. I want to type in "acme" in to the name field, and have it pull up a list of known Acme's (Acme Explosives, Acme Jet Boots, Acme Atomic Pogo Sticks), and from there I'd select the relevant entry (#132524), and that gets entered in to the form for me. Same with items. How do you do data selection during data entry? The problems with this in the web environment is that it typically involves popups and intra window communications. Which means more state transfers and games. In most rich GUIs, these pickers are Modal. So, these are a challenge for web app writers to do. As for the items that aren't Stripes specific, I look at the book as more "building application with Stripes" rather than "Here's what stripes can do". For example, security has nothing to do with stripes (unless you use the Interceptor add on, but it's not used in BZ for example). But it's still an important component of any application. And I'm thinking of BZ 2 being a solid, open application showing all sorts of techniques -- many Stripes specific, but also just helpful for any application. I think BZ should send emails (for notifications of new action on an issue, for example). The Stripes techniques are less useful without context. Applications put the Stripes mechanisms in place, and in context, showing how and where they should be used. By using the meme of building an application, and then using Stripes to do it, you convey all sorts of interesting information, especially to folks new to the platforms (Java, the web, Stripes, ORM technologies, etc.). And, again, in the end you get an interesting application, usable standalone with zero knowledge of Stripes, but at the same time a poster child for overall good practices. And what happens is when folks see something like that, they tend to take the whole kit. Most folks are simply not passionate about their tools. They just want tools that work. If you give someone examples that step them up to what they want to do, they'll use them. They're not going to say "Wow, that's a neat app, I'll rewrite it with Struts 2". They simply won't bother. So that's the advantage of providing a good, solid, benchmark application built upon the framework. The whole paradigm presented by it gets adopted and tweaked. That's what I did with the original Bugzooky. I simply hammered it in to shape and learned that it wasn't best way to do things. But it got my first cut up and running and functional. Give me a better example, and my applications will be better as well. And when you give contrived examples that don't work in the real world, guess what? They get copied wholesale in to "real world" applications that then, later, don't work. Shocking. So, provide good tools (Stripes) with outstanding examples, and that will drive traffic. "Gee, Struts 2 and Stripes are 'the same', but half of my infrastructure is right here in BZ 2, so I'll go with Stripes because I get so much more 'for free'." Yet, even with all that, Stripes remains a lightweight framework. Unlike, say, Seam, which is a large piece of kit, Stripes would be a lightweight focused piece of kit with, hey wow, a really nice example of how it's used in the real world. Regards, Will Hartung |
|
|
Re: Stripes Ignored...Again
by Jeppe Cramon
::
Rate this Message:
Hi
> > I'm not sure I understand what a header / details screen is. > > Really? What different worlds we live in. Maybe it's a vocabulary thing... > > But, I'll explain. > > The classic example is ye olde Order Entry. Most systems break orders in > to > two pieces: the order itself, and the items in the order. The order is the > "header" and the items are the "detail. The order captures the date, the > customer, perhaps order terms, etc. The items list each item on the order: > 1 > vcr, 1 MP3 player, 4 blank video tapes. I think it's a vocabulary thing, I've learned that these are called master/detail screens, so maybe that clears it out for others? /Jeppe ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: Stripes Ignored...Again
by marijan milicevic
::
Rate this Message:
agreed, better site and new domain maybe (www.stripes-framework.org is free, I'll donate money for domain registration), -m [quote] Second, Stripes does not require a book yet. First of all, Stripes needs a better website, which correlates with the lightweight and extensible character of Stripes. Think about it, when you open the website of Ruby on Rails (like http://www.rubyonrails.org/screencasts). Stripes should not try to convince developers not to use Struts or Seam etc. Most of the developers out there do know Struts and if they hit the website, they are already interested in another / a better approach to things. [/quote] ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: Stripes Ignored...Again
by Aaron Porter-3
::
Rate this Message:
I've got my own server that we can host it on and actually run Stripes
apps. :) Aaron Marijan Miličević wrote: > agreed, better site and new domain maybe (www.stripes-framework.org is free, I'll donate money for domain registration), > > -m > > > > [quote] > > Second, Stripes does not require a book yet. First of all, Stripes needs a better website, which correlates with the lightweight and extensible character of Stripes. Think about it, when you open the website of Ruby on Rails (like http://www.rubyonrails.org/screencasts). Stripes should not try to convince developers not to use Struts or Seam etc. Most of the developers out there do know Struts and if they hit the website, they are already interested in another / a better approach to things. > [/quote] > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
| < Prev | 1 - 2 - 3 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
