Example TwitteRIA App
Posted by xtyler in Uncategorized on 06 5th, 2009 | 5 responses
Tony Hillerson wrote a framework-comparison series on InsideRIA last year. He built the same twitter client 5 times to offer a thorough evaluation of each framework, a good read if you haven’t yet seen the articles.
Though Flight wasn’t in the public eye at the time, it has finally caught up. Tony hasn’t yet reviewed the framework, but the twitter client known as TwitteRIA is now available as a Flight application. It’s a good example app and nice for comparing Flight with your favorite framework. The source is here.
Enjoy!
5 Responses to “Example TwitteRIA App”
Leave a Reply
Hello,
the example isn’t working with latest release. Seems like some method chaining has been removed in the Response class.
Do you have any working example with rc 1.0 ?
I am going to start a project really soon and was really interested in using your framework. Is it finished enough to start working on it or should we expect lots of modifications in the future ?
Also, are you going to release more documentation and examples soon ?
Keep up the good work.
While I’m here, I have another question regarding the example:
shouldn’t the Login & Main view be located in twitteria.domains.twitter.view package since they are only linked to the TwitterDomain ?
I am really interested in this domain concept. Feels like a good way to structure code in a reusable plugin fashion.
The “Flight Framework: Application Structure” post isn’t enough, it would be really nice to have additional explanations and examples for this particular point.
Oh, and sorry for the annoying requests / questions, I’m just eager to start working with flight.
Yann,
You’re right, the project is ahead of the examples and documentation. I’m working now to finish up the docs and update the examples - the only thing left before a full 1.0 release.
In regards to the view being on the application root or in the domain - it’s completely up to the developer and what you’d like to achieve. In one train of thought your view is specific to the application, to the design and the UX of the app as a whole. On the other side your view may be specific to your domain and ignorant of the other application elements.
I think I’m with you on this one, it would be cleaner to build domain-specific view components and store them with the domain. However, if usability suggests a control panel spanning several domains then I’d keep it up on the app level. What do you think?
Hello,
sorry for the late reply.
For me, it makes more sense to keep the domain specific view within its domain because I really need the domains to work as re-usable plugins for other applications.
But you’re probably right, there will be some situations where you need one view component to access several domains, and you’ll have to put it at the app level.
It makes me think that in more complicated situations it would even be useful to do some domain nesting, having a domain containing other sub-domains. In that case, the component would go in the top domain and could access the two sub domains in a cleaner way.
That would probably be overkill in most situations but I think it deserves some thinking.
What is the best way to send you feedback in the future ? There are a few things I’d like to discuss regarding my experiments with the framework…
Regards,
Yann
Yann - You’re right, components and views that are portable with your domain should be inside your domain. Another consideration you may consider refactoring your domain package into the top-level package (outside of the application) to be used as a shared library.
You are more than welcome to join the Flight Framework mailing list. And of course I appreciate your comments here as well, thanks!