Re: Migrating from BlazeDS to GraniteDS
> Parsley is dead since February 2012 (2 years) I like to call it 'stable'. ;) > there is no good reason why you couldn't use Parsley meta tags > together with GraniteDS / Tide Might be worth looking into it. Can the tags be renamed easily? [InjectTide] maybe? Am 19.03.2014 10:31, schrieb Franck Wolff: > Parsley is dead since February 2012 (2 years), based on the date of the > last release (http://www.spicefactory.org/parsley/download.php)... Sorry, I > couldn't resist ;) > > More seriously, if you want to keep Parsley, it would be interesting to dig > into these incompatibility issues with GraniteDS / Tide: there is no good > reason why you couldn't use Parsley meta tags together with GraniteDS / > Tide (at least data management, paged queries, etc., but without Tide's > redundant meta tags). We already know people using successfully Parsley and > Tide. > > > 2014-03-18 18:55 GMT+01:00 dude : > >> I would like to convert our current project to GraniteDS & Tide, if it >> wasn't for the incompatibility with Parsley meta tags ([Inject], etc). :( >> >> Am 18.03.2014 17:19, schrieb Franck Wolff: >>> Hi, >>> >>> We have republished and updated a quick migration guide from BlazeDS to >>> GraniteDS on our blog here: >>> >> http://www.granitedataservices.com/2014/03/18/migrating-from-blazeds-to-graniteds/ >>> >>> AFAIK, BlazeDS is dead for about 3 years, as well as Spring-Flex. On the >>> other hand, GraniteDS is still very active and supports all new Spring / >>> Java EE technologies. >>> >>> Just a quick reminder ;) >>> >>> Franck. >>> >> >
Re: Migrating from BlazeDS to GraniteDS
I would like to convert our current project to GraniteDS & Tide, if it wasn't for the incompatibility with Parsley meta tags ([Inject], etc). :( Am 18.03.2014 17:19, schrieb Franck Wolff: > Hi, > > We have republished and updated a quick migration guide from BlazeDS to > GraniteDS on our blog here: > http://www.granitedataservices.com/2014/03/18/migrating-from-blazeds-to-graniteds/ > > AFAIK, BlazeDS is dead for about 3 years, as well as Spring-Flex. On the > other hand, GraniteDS is still very active and supports all new Spring / > Java EE technologies. > > Just a quick reminder ;) > > Franck. >
Re: Parsley question
The introduction to chapter 11 of the Parsley documentation [1]: "11 - Building MVC Architectures Parsley is different from several other Flex or Flash MVC Frameworks in that it does not provide very much explicit support for the various pieces of an MVC architecture. This was a side effect of our primary goal being to allow to design a fully decoupled architecture. Decoupled in a sense that not only the parts of your application are decoupled from each other, but also decoupled from the framework itself. For example providing base classes for controllers or mediators in the framework that application classes have to extend is a bad idea if you want to support such a decoupled architecture. For that reason the Messaging Framework in Parsley which we already described in 6 Messaging is pretty generic. It does not assume a particular programming style or architectural pattern. Nevertheless Parsley still falls into the same category as many other MVC Frameworks since the Messaging Framework can easily be used in a way that helps building an application based on the MVC architectural pattern. In this chapter we will provide some examples on how to use the Messaging Framework in such a context." Reading that chapter [2] might give you more insight. [1] http://www.spicefactory.org/parsley/docs/3.0/manual/ [2] http://www.spicefactory.org/parsley/docs/3.0/manual/mvc.php#intro Am 26.10.2013 02:53, schrieb mark goldin: > How exactly Parsley is releasing mediators? > > > On Fri, Oct 25, 2013 at 5:36 PM, Maurice Amsellem < > maurice.amsel...@systar.com> wrote: > >> >> i do >> >> Maurice >> ___ >> De : mark goldin [markzolo...@gmail.com] >> Envoyé : vendredi 25 octobre 2013 22:48 >> À : users >> Objet : Parsley question >> >> Anybody is working with Parsley framework? >> >> Thanks >> >
Re: adobe flex vs apache flex
You're right, helping people with their immediate problem is important, and I actually did provide him with a link that should answer his questions, so I wasn't saying "go away, do your homework" at all. Still, research is a key skill for a developer, no matter the technology or learning-state you are in. Whatever, wrong place for that topic. EOD IMHO. Am 14.08.2013 14:57, schrieb Carlos Velasco: > I think at the moment new people coming to flex world is to be welcomed > rather than being someway thrown away by a "rude" "Make your homework first > and search the Internet properly before asking nonsense, please"... > > I have always found those kind of forum responses quite useless... When > someone doesn't know about something, he/she also doesn't know what to look > for or where to find exactly the contents that may make they pass their > learning curve. > > So let's take some tolerance with newbies and try to guide them instead of > being so overbearing. Maybe not talking the same things again and again, > but giving them direct links to begin with or so. > > > 2013/8/14 dude > >>> Because I am new in flex, once I search some questions in google, I will >>> find most of them links will refer to the adobe site. >> >> How can you not check Wikipedia first if there is an article about Adobe >> or Apache Flex at all? I'm sure it answers most of your questions. Here, >> let me help you: http://en.wikipedia.org/wiki/Apache_Flex >> >> On a side note: So, is that how people start using new technologies >> nowadays? Going straight to the mailing list asking people about the >> most basic things? What about some research first? Usually you should >> read as much as possible of the available information on the internet >> yourself before you start asking questions like this. Wikipedia is >> usually a good starting point for that. >> Don't get me wrong, you will get answers here because people are nice >> and like to share their knowledge, this is what OSS is all about. But >> it's a PITA to answer such questions over and over again just because >> someone can't do the most basic online search. Some really weird >> research you got there ... >> >
Re: adobe flex vs apache flex
> Because I am new in flex, once I search some questions in google, I will > find most of them links will refer to the adobe site. How can you not check Wikipedia first if there is an article about Adobe or Apache Flex at all? I'm sure it answers most of your questions. Here, let me help you: http://en.wikipedia.org/wiki/Apache_Flex On a side note: So, is that how people start using new technologies nowadays? Going straight to the mailing list asking people about the most basic things? What about some research first? Usually you should read as much as possible of the available information on the internet yourself before you start asking questions like this. Wikipedia is usually a good starting point for that. Don't get me wrong, you will get answers here because people are nice and like to share their knowledge, this is what OSS is all about. But it's a PITA to answer such questions over and over again just because someone can't do the most basic online search. Some really weird research you got there ...
Re: IDE for Apache Flex
1. Not sure what your point with 32- & 64-bit is about, but working with a 32 bit program on a 64 bit machine is totally fine. 2. If you want to stick with Eclipse and just need to replace Flashbuilder, you might want to have a look at FDT: http://fdt.powerflasher.com/ Am 10.08.2013 20:58, schrieb Daniel D: > Hello Matt, > > I do not know IntelliJ, but I've heard it, I'm User of Eclipse and would > not trade for anything. Flash Builder is excellent, but in version 4.7 > 64-bit, removed the design view. My computer is 64 bit, but I have to use > version 4.6 32-bit for it. > > I believe that an IDE based on Eclipse 32 or 64 bits easy to use, free, > Opensource, popularize Apache Flex, which has been losing a lot for HTML5. > > Thanks. > > 2013/8/10 Mathieu St-Gelais > >> I understand your point. If you're already paying for Flash Builder, you >> could instead pay for IntelliJ (approximately the same price). It is, in my >> opinion, a brilliant IDE and it works great with Apache Flex. >> >> Mat >> >> >> On Sat, Aug 10, 2013 at 2:28 PM, Daniel D wrote: >> >>> I would love to participate in an open source project, but I have no >>> experience in creating plugins for Eclipse or time to learn now, but I >>> think an IDE with good resources becomes more attractive language for new >>> programmers. window components and drag components. the problem is the >>> alignment of the components, it takes a long compile to see the swf in >> the >>> browser. >>> >>> I program in Java and Flex to 8 years, and use Flash Builder 4.6 in 32 >> bit >>> mode, not like the 4.7 64-bit. >>> >>> Thanks. >>> >>> >>> 2013/8/10 Jeffry Houser >>> On 8/10/2013 1:48 PM, Daniel D wrote: > The Apache will create an IDE for Flex, based on Eclipse 64 bit ? > I have not heard of any plans to create a full fledged IDE. But, if >> you think this is important, I strongly encourage you to start. Because the latest version of Adobe Flash Builder 4.7 64 bit is >>> horrible, > removed the display design for mxml, why? > We have been told that design view was removed because it was very difficult to update; was not flexible enough to support multiple >> versions of Flex; and was very rarely used by developers. If memory serves me; there was an AIR Based replacement for design >> view that was demoed relatively recently. You are more than welcome to create one or start one if you think it >> is important. -- Jeffry Houser Technical Entrepreneur http://www.jeffryhouser.com 203-379-0773 >>> >> >
Re: MVC framework
Well, that wasn't meant to be defensive, just some information to clear things up a bit. Also I'm sure other frameworks are great, too, but this is not a competition. It's about picking the right tools for a task. And I do love Parsley because it gets the job done in a very effective and smart way. If it would not do that, I'd switch to a tool that does. Being a developer requires to be flexible and open to change in many aspects. Chosing proper tools is an essential skill. Parsley is not the solution to everything, and there is always the possibility that it gets replaced by something else (unlikely, but if ever, I'd pick GraniteDS). Am 26.07.2013 20:35, schrieb Ajar: > Go Parsley!!! > That's it. you got me there! > I'm converted... > :) > > We love our tools so much we are ready to stand on our back feet to defend > them with so much passion. > Switched on and ready to get into that ring!!! > Like JS/flash rivals or any other technology fighting to dominate > Sometime it gets to a point where I can actually see how holy wars tick... > What is this I wonder? righteousness? an erg to save the community? > protecting one's own investment? prestige-a-la-geek? ego? all of the above? > as a flash/flex dev I feel on a witch hunt in the past year or two > here I can breath among my own peers ah. > chop up some garlic & parsley, comes along nicely with some Mediterranean > Te'hina, and enjoy your self. > Have a great weekend > :) > > On Fri, Jul 26, 2013 at 9:04 PM, dude wrote: > >> 1. Parsley is OSS, the repo is at github, so everyone can start working >> if there is need to do so (that hasn't been the case yet, because it >> works great out of the box). The original author moved on to other >> projects though, but that happens a lot and does not make Parsley any >> less valuable. >> >> 2. About complexity: complex != complicated and simple != easy. >> >> You can use every tool in a complex (possibly wrong) and easy (possibly >> correct) way. You can use a hammer wrong if you grab it on the wrong >> end, but it will get the job done eventually. So "Overkill" might not be >> the right word, better go for "wrong usage" or "over complicated usage". >> Parsley is simple if used properly. >> >> 3. Usage: Parsley basically comes down to IoC/DI (e.g. via [Inject] >> tags), Commands and Messages. Everything is wired together in (M)XML in >> the simples possible way. Once you've set it up it's absolutly simple in >> everyday work (read: efficant). There are some advanced features >> (Scopes, decoupled bindings, etc) which are optional. You don't have to >> use them if you don't need to, but if you do, it's great to have them >> available. The framework can also be manually improved in many ways >> (interceptors, etc). >> Another important part is documentation: Everything is well documented >> and explained(!). There could be more examples available though. So it >> might take some time to get things working, depending on your knowledge >> on AS3, Flex, software engineering, etc. >> >> Summed up, it's a stable, robust, extensible piece of software, that >> scales perfectly. >> >> Am 26.07.2013 14:21, schrieb Ajar: >>> In my opinion - overkill is indeed the right word to describe parsley in >>> most cases. >>> While I respect complexity and clockwork architecture, >>> I can really appreciate straight forward framework like RobotLegs which >>> reduces the complexity in my projects. >>> My projects are fairly complex and large scale, this is why RL was a >> treat, >>> since I didn't need to double (or triple) the complexity. >>> I'm not looking for extensive feature-set that I'll rarely get to, I'd >>> rather have 80% which covers most cases in an easy straight-forward way. >>> And while you argue the parsley is close to perfection, indeed try it out >>> and see for your self, while having a project to execute, will you >> prefer a >>> robust tool or a minimalist one. >>> In my opinion, you are bound to go astray while you go into a new >>> territory, that's why a community is essential to support and grow >>> according to real needs that are communicated within a live community, >>> rather then browsing through ghost-posts hoping it will stick. >>> RL approach to modules in particular was a relief after trying out >> plumbing >>> with pureMVC pipes... >>> simple, painless, and works like a charm. >>> good luck with it, any turn y
Re: MVC framework
1. Parsley is OSS, the repo is at github, so everyone can start working if there is need to do so (that hasn't been the case yet, because it works great out of the box). The original author moved on to other projects though, but that happens a lot and does not make Parsley any less valuable. 2. About complexity: complex != complicated and simple != easy. You can use every tool in a complex (possibly wrong) and easy (possibly correct) way. You can use a hammer wrong if you grab it on the wrong end, but it will get the job done eventually. So "Overkill" might not be the right word, better go for "wrong usage" or "over complicated usage". Parsley is simple if used properly. 3. Usage: Parsley basically comes down to IoC/DI (e.g. via [Inject] tags), Commands and Messages. Everything is wired together in (M)XML in the simples possible way. Once you've set it up it's absolutly simple in everyday work (read: efficant). There are some advanced features (Scopes, decoupled bindings, etc) which are optional. You don't have to use them if you don't need to, but if you do, it's great to have them available. The framework can also be manually improved in many ways (interceptors, etc). Another important part is documentation: Everything is well documented and explained(!). There could be more examples available though. So it might take some time to get things working, depending on your knowledge on AS3, Flex, software engineering, etc. Summed up, it's a stable, robust, extensible piece of software, that scales perfectly. Am 26.07.2013 14:21, schrieb Ajar: > In my opinion - overkill is indeed the right word to describe parsley in > most cases. > While I respect complexity and clockwork architecture, > I can really appreciate straight forward framework like RobotLegs which > reduces the complexity in my projects. > My projects are fairly complex and large scale, this is why RL was a treat, > since I didn't need to double (or triple) the complexity. > I'm not looking for extensive feature-set that I'll rarely get to, I'd > rather have 80% which covers most cases in an easy straight-forward way. > And while you argue the parsley is close to perfection, indeed try it out > and see for your self, while having a project to execute, will you prefer a > robust tool or a minimalist one. > In my opinion, you are bound to go astray while you go into a new > territory, that's why a community is essential to support and grow > according to real needs that are communicated within a live community, > rather then browsing through ghost-posts hoping it will stick. > RL approach to modules in particular was a relief after trying out plumbing > with pureMVC pipes... > simple, painless, and works like a charm. > good luck with it, any turn you take. > cheers > Ajar > > On Fri, Jul 26, 2013 at 2:06 PM, Maurice Amsellem < > maurice.amsel...@systar.com> wrote: > >> Fully agree with Thomas. >> Although Parsley will not evolve anymore from its creator, it's very >> mature and capable, almost bug free, and it's very extensible: >> - either from native documented extension points >> - with directly by modifying the source. >> >> So it may be overkill for small projects, but it really shines on complex >> or large projects. >> I also used it on Mobile Flex (using the FastInject feature) with little >> performance degradation. >> >> Regards, >> >> Maurice >> >> -Message d'origine- >> De : Frédéric Thomas [mailto:webdoubl...@hotmail.com] >> Envoyé : vendredi 26 juillet 2013 10:55 >> À : users@flex.apache.org >> Objet : Re: MVC framework >> >> Hi, >> >> Just to be clear even though Parsley is not maintain anymore by its >> original creator, it's up to individuals to add new feature as they like, >> it's the more complete and well design IOC / MVC framework I used out >> there, it has everything you need out of the box and probably more, that's >> the point, depending of your project complexity, you maybe won't need all >> its capabilities, in this case, a lighter and easier to learn framework >> will probably fit your needs as Swiz, Roboleg, Urania or even a custom one. >> >> -Fred >> >> -Message d'origine- >> From: Ajar >> Sent: Friday, July 26, 2013 10:23 AM >> To: users@flex.apache.org >> Subject: Re: MVC framework >> >> dude - Parsley is discontinued, you can checkout the news section on their >> site. >> RobotLegs on the other hand is alive and kicking! >> Great supportive community, and you'll pick it up on a weekend. >> well, i'm biased - it&
Re: MVC framework
0. There is not 'the best' and you don't really need it, as Flex/AS3 itself is already capable of MVC/MV(V)P itself. 1. Tide (GraniteDS) - most complete solution replacing BlazeDS/LCDS. Tide is GraniteDS's IoC framework. I'd pick this for a new project. [1] 2. Parsley (my favorite) - IMHO the best decoupling framework out there. It's great and has everything you need for MVC/MVP or IoC/DI. We love it. [2] 3. Swiz - might be donated to Apache soon. Haven't used it myself in production, but gets recommended every now and then. [3] 4. Some more here: http://www.spoon.as/ecosystem/application-frameworks/ [1] http://www.graniteds.org/ [2] http://www.spicefactory.org/parsley/ [3] https://github.com/swiz/
Re: Inversion of Control
We use Parsley 3 in our current project and - simply put - we just love it. Go for it! If I'd start with a new project I would propably look into GraniteDS (which provides the Tide framework for IoC), mostly because the remoting is far more advanced than BlazeDS is. Am 28.05.2013 20:00, schrieb Mathieu St-Gelais: > Hi everyone. This is my first message in the mailing list, but I've been > following for a while now... > > Just so you know, I've been developing in Adobe Flex for the past 3 or 4 > years, and I'm going to move to Apache Flex with my next project that > starts in two weeks. > > I have a question for your guys: it seems that both Parsley and Swiz > frameworks are "dead", as in inactive. I suppose one could continue using > them, but I would like to know what would be your application framework of > choice as of today. I'm looking for IoC features, decoupled bindings, etc. > > I need something production-ready as this application will be in production > in January 2014, and my client will probable use (and add new features to > it) it for many years. > > Thanks a lot for your time and help! > > Matt >
Re: looking for group development input
> SCM Do not use SVN. Use hg (aka Mercurial) or git. You also might want to use something like RhodeCode if you need multiple repositories and don't to pay for bitbucket/gitbub for private repositories (and you WILL need multiple repositories once you've shipped your software). > Flash Builder 4.6, IntelliJ, FDT If developers work remotely they usually have their IDE already set up and know how to work with it, so don't waste time or money before you've talked to them about their setup and prefered working environmnent. If you still need to buy them I would go for for IntelliJ or FDT (actually the latter, because Eclipse). > VMWare VM machines with an IDE, Tomcat server, etc: If you still REALLY need that you could use something like Vagrant + Ansible. > Project Management? JIRA is quite popular. We use Redmine over here, works great, OSS and is actively developed. It also can keep track of the time spent for each ticket (keep in mind that time-spent doesn't neccessarily correlate with the actual complexity of task). There is also a Mylyn-connector available, so developers can use it within Eclipse. > OwnCloud Just do not use DropBox. :) You might also need a groupware server like SOGo. > else Use tools like like Jenkins for continuous delivery. These are many questions and they highly depend on your needs, which usually change over time. So just get started with a small setup with some widely used tools. As a guideline, our setup in short: - FlashBuilder 4.6 - hg + RhodeCode - Redmine + Mylyn - Jenkins - SOGo Good luck.
