From: <gi...@gm...> - 2011-01-22 12:11:47
|
So, it is a long time since I started brewing this idea, that is, start using an higher level tool to build new stuff and gradually rewrite old one. Several times I found in the Zend Framework (but I'm pretty sure that's not only Zend, it just represents a modern and maintained piece of PHP code) the tools needed to easily replace our external dependencies or implement new features; for instance, I had a branch where I got rid of rssbuilder replacing it with Zend_Feed and another one with openID auth working with Zend_Auth However, the "gradually rewrite" part was the hardest one to achieve and it was obvious that without a good plan for the transition I could not possibly propose to stop development and redirect all developers in a grand rewrite with little hope for success. Fast forward to today, I am happy to let you know I managed to prepare a branch that fills that gap, so it would be possible to start developing new stuff with this new system, while retaining the old code and pages until a replacement is ready. The branch is called "manzen" and lives here: https://github.com/giallu/mantisbt/tree/manzen Right now it's a minimalistic wrapper so that every request is passed through pubilc/index.php, checked against the /legacy directory and, when the requested page exists, served from there. Now the plan is to understand how we could start moving stuff from legacy, I hope to take on this task soon. I encourage everyone interested to try cloning the repo and having a look around the (little) code I added to do this trick. Of course, I will be more than happy to discuss both general issues and implementation details, so feel free to post your opinion on the topic. Cheers G. -- Gianluca Sforna http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu |
From: Udo S. <u.s...@gm...> - 2011-01-22 13:34:49
|
Hello Gianluca, this looks promising. I will keep an eye on this branch and if I see I am able to contribute, I will do so. Thanks, Udo |
From: Udo S. <u.s...@gm...> - 2011-01-23 19:05:06
|
hello, not quite sure if a starting point could be this (just some ideas) - define whether or not to use modules note: in my opinion there should be modules. - define the modules/controllers/actions (naming) to have a rough structure - assign legacy code to the module/controller/action where it would be handled - define the sequence of rewriting legacy code functionalities best, udo |
From: Joanna C. <jo...@th...> - 2011-01-23 20:35:43
|
Hi, I would like to second the notion of using modules - definitely you'd otherwise end up with too many actions per controller to be manageable. Also what were you thinking of using for db abstraction? Zend, Doctrine, something else? Regards, Joanna On 23 January 2011 19:04, Udo Schochtert <u.s...@gm...> wrote: > hello, > > not quite sure if a starting point could be this (just some ideas) > > - define whether or not to use modules > note: in my opinion there should be modules. > - define the modules/controllers/actions (naming) to have a rough > structure > - assign legacy code to the module/controller/action where it would be > handled > - define the sequence of rewriting legacy code functionalities > > best, udo > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better > price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > |
From: Robert M. <rob...@gm...> - 2011-01-24 11:37:21
|
On Sat, Jan 22, 2011 at 2:11 PM, gi...@gm... <gi...@gm...> wrote: > > Fast forward to today, I am happy to let you know I managed to prepare > a branch that fills that gap, so it would be possible to start > developing new stuff with this new system, while retaining the old > code and pages until a replacement is ready. > > The branch is called "manzen" and lives here: > https://github.com/giallu/mantisbt/tree/manzen > Hi, I think it's a great kick-off and I would +1 to get this merged into master while master is still unstable enough for clients to try. There are many tests which I would like to make , including the SOAP API, but I would say that if the consensus it to get behind the Zend framework, push this to master and then we test. Robert -- Sent from my (old) computer |
From: <gi...@gm...> - 2011-01-26 00:25:03
|
On Mon, Jan 24, 2011 at 12:37 PM, Robert Munteanu <rob...@gm...> wrote: > > I think it's a great kick-off and I would +1 to get this merged into > master while master is still unstable enough for clients to try. I think it's right now it's not worth pushing to master as it just adds a new (someone would say large) dependency while not giving enough benefits. I guess we could revise the decision any time if the branch gains enough traction. -- Gianluca Sforna http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu |
From: Olivier B. <oli...@it...> - 2011-01-24 12:11:56
|
Hi. Le samedi 22 janvier 2011 à 13:11 +0100, gi...@gm... a écrit : > > Fast forward to today, I am happy to let you know I managed to prepare > a branch that fills that gap, so it would be possible to start > developing new stuff with this new system, while retaining the old > code and pages until a replacement is ready. > > The branch is called "manzen" and lives here: > https://github.com/giallu/mantisbt/tree/manzen > May I suggest you also have a look at our implementation of a REST API conforming to OSLC-CM that we developped as a Zend controller/router, etc. I think it would be great to have it merged with your code, then, so that the same controller/router can handle all GET POSTs relating to the wrapping you mention, and also the "direct" REST PUTs and DELs, etc. See pointers at : http://www.mantisbt.org/bugs/view.php?id=11063 Hope this helps. Best regards, -- Olivier BERGER <oli...@it...> http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingénieur Recherche - Dept INF Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France) |
From: <gi...@gm...> - 2011-01-26 00:26:51
|
On Mon, Jan 24, 2011 at 1:11 PM, Olivier Berger <oli...@it...> wrote: > May I suggest you also have a look at our implementation of a REST API > conforming to OSLC-CM that we developped as a Zend controller/router, > etc. > > I think it would be great to have it merged with your code, then, so > that the same controller/router can handle all GET POSTs relating to the > wrapping you mention, and also the "direct" REST PUTs and DELs, etc. > Yeah, that definitely looks like a terrific piece of work. I'll try to evaluate the potential for an early merge before moving on more concrete stuff. -- Gianluca Sforna http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu |
From: <gi...@gm...> - 2011-01-26 00:24:20
|
On Sun, Jan 23, 2011 at 9:35 PM, Joanna Chlasta <jo...@th...> wrote: > I would like to second the notion of using modules - definitely you'd > otherwise end up with too many actions per controller to be manageable. Ok, this is the first time I actually think about using Zend as base for a large project, so I'm not really sure about the implications of using modules or not. In particular, do anyone know if we can easily move to use modules later? > Also what were you thinking of using for db abstraction? Zend, Doctrine, > something else? Recently, I made a couple scripts to aide merging two mantis instances and I used the Zend abstraction layer; it was a decent experience so right now I have a fairly complete set of Mantis_Table_* classes extending from Zend_Db_Table_Abstract. These was for Mantis 1.1 but I think I should be able to port these to master with relative effort. I found the Zend_Db abstraction to be at a comfortable level, high enough to avoid writing SQL (which was one of my primary goals) but I'll avoid comparing it to other ORM systems since I really did not try anything else. Again I'd start with this base and move away when/if we find problems down the road. I hope this sounds like a plan :) -- Gianluca Sforna http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu |
From: Udo S. <u.s...@gm...> - 2011-01-26 14:35:32
|
> > Ok, this is the first time I actually think about using Zend as base > for a large project, so I'm not really sure about the implications of > using modules or not. > It is considered to start with modules from the start (if you alredy know that you are bilding a large project) because you already have to think about the structure from the beginning... > In particular, do anyone know if we can easily move to use modules later? > Adding modules or moving controllers around modules requires little refactoring. Best, Udo |
From: Robert M. <rob...@gm...> - 2011-01-27 11:47:06
|
On Wed, Jan 26, 2011 at 2:23 AM, gi...@gm... <gi...@gm...> wrote: > On Sun, Jan 23, 2011 at 9:35 PM, Joanna Chlasta > <jo...@th...> wrote: >> I would like to second the notion of using modules - definitely you'd >> otherwise end up with too many actions per controller to be manageable. > > Ok, this is the first time I actually think about using Zend as base > for a large project, so I'm not really sure about the implications of > using modules or not. > > In particular, do anyone know if we can easily move to use modules later? > >> Also what were you thinking of using for db abstraction? Zend, Doctrine, >> something else? > > Recently, I made a couple scripts to aide merging two mantis instances > and I used the Zend abstraction layer; it was a decent experience so > right now I have a fairly complete set of Mantis_Table_* classes > extending from Zend_Db_Table_Abstract. These was for Mantis 1.1 but I > think I should be able to port these to master with relative effort. > > I found the Zend_Db abstraction to be at a comfortable level, high > enough to avoid writing SQL (which was one of my primary goals) but > I'll avoid comparing it to other ORM systems since I really did not > try anything else. Again I'd start with this base and move away > when/if we find problems down the road. > > I hope this sounds like a plan :) We currently have _many_ issues open related to our db layer [1] . Do you think that Zend_DB will be a better fit? Zend_DB also seems to have SQLite support, which is interesting for me from two reasons: - ability to bootstrap Mantis using just a Java servlet container ( using Resin's Caucho and ZendDB's SQLite support ); - much easier management for integration tests, which allows us to easily 'swap' the database content when needed. Robert [1]: http://www.mantisbt.org/bugs/search.php?project_id=1&category[]=db%20db2&category[]=db%20mssql&category[]=db%20mysql&category[]=db%20oracle&category[]=db%20postgresql&status_id[]=10&status_id[]=20&status_id[]=30&status_id[]=40&status_id[]=50&sticky_issues=off&sortby=last_updated&dir=DESC&hide_status_id=-2 > > > > -- > Gianluca Sforna > > http://morefedora.blogspot.com > http://identi.ca/giallu - http://twitter.com/giallu > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > -- Sent from my (old) computer |
From: Udo S. <u.s...@gm...> - 2011-01-27 14:12:09
|
> We currently have _many_ issues open related to our db layer [1] . Do > you think that Zend_DB will be a better fit? Zend_DB also seems to > have SQLite support, which is interesting for me from two reasons: > > - ability to bootstrap Mantis using just a Java servlet container ( > using Resin's Caucho and ZendDB's SQLite support ); > - much easier management for integration tests, which allows us to > easily 'swap' the database content when needed. Zend_Db knows to handle quite a few DB Adapters: http://framework.zend.com/manual/en/zend.db.adapter.html with them it is quite easy to interconnect to the supported DBs. It's also should be quite easy to use your preferred DB locally or run unit tests against various DBs (did not try this yet...) best, udo |
From: Udo S. <u.s...@gm...> - 2011-01-27 14:38:35
|
I forgot to mention that I prefer using doctrine as an db abstraction layer. the great advantage is to use data fixtures (Link<http://www.doctrine-project.org/projects/orm/1.2/docs/manual/data-fixtures/en>). this way you can ensure to always start from a defined starting point (from a data point of view) when testing (or unit testing). -> as already mentioned by some people, doctrine is worth to be considered. best, udo |
From: <gi...@gm...> - 2011-02-01 22:26:13
|
On Thu, Jan 27, 2011 at 3:38 PM, Udo Schochtert <u.s...@gm...> wrote: > I forgot to mention that I prefer using doctrine as an db abstraction layer. > the great advantage is to use data fixtures (Link). this way you can > ensure to always start from a defined starting point (from a data point of > view) when testing (or unit testing). -> as already mentioned by some > people, doctrine is worth to be considered. Yeah, I'd rather try to stick with the Zend provided stuff but doctrine is definitely a very nice project. Can you check if the following covers (at least partially) the data fixtures issue? http://framework.zend.com/manual/en/zend.test.phpunit.db.html Cheers G. -- Gianluca Sforna http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu |
From: Udo S. <u.s...@gm...> - 2011-02-03 08:29:03
|
> Can you check if the following covers (at least partially) the data > fixtures issue? > http://framework.zend.com/manual/en/zend.test.phpunit.db.html that should work also. Also check this: http://www.slideshare.net/DragonBe/unit-testing-after-zf-18 (slide 62..) best, udo On Tue, Feb 1, 2011 at 11:25 PM, gi...@gm... <gi...@gm...> wrote: > On Thu, Jan 27, 2011 at 3:38 PM, Udo Schochtert <u.s...@gm...> > wrote: > > I forgot to mention that I prefer using doctrine as an db abstraction > layer. > > the great advantage is to use data fixtures (Link). this way you can > > ensure to always start from a defined starting point (from a data point > of > > view) when testing (or unit testing). -> as already mentioned by some > > people, doctrine is worth to be considered. > > Yeah, I'd rather try to stick with the Zend provided stuff but > doctrine is definitely a very nice project. > > Can you check if the following covers (at least partially) the data > fixtures issue? > http://framework.zend.com/manual/en/zend.test.phpunit.db.html > > Cheers > > G. > > > -- > Gianluca Sforna > > http://morefedora.blogspot.com > http://identi.ca/giallu - http://twitter.com/giallu > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better > price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |