Planning for Taffy 2.0

[Adam Tuttle]

I think the time has come to start working on Taffy 2.0. The current feature set seems to be stable and sufficient and bugs are few and far between.

Two things that I'd really like to address in 2.0:

• Get rid of everything that's been deprecated to date. Not an insignificant amount of code.
  
• Refresh the dashboard.
• Ultimately I'd love it if this were to use something like Swagger, and I'll look into it, but falling short of that, I may just try to make it less ugly.
• If going with the "less ugly" approach, Bootstrap would be a consideration, but I'd really rather not include a bunch of bootstrap files in the Taffy repo. This begs the question: Do you ever use the Taffy dashboard when you don't have an internet connection? It'd work to include Bootstrap stuff from a CDN, but only if you're online.

Something else that's been on my mind lately is abandoning the custom function names I created in Application.cfc for the traditional "onApplicationStart" and "onRequestStart". Doing so would require that you remember to include "super.onApplicationStart();" in your Application.cfc, and to do it at the right point in your implementation, which is a con. The matching pro is that everyone is familiar with these methods and it feels more natural, and would probably also be easier to remember the method names (if you have trouble remembering them, currently). It also gives you more control, if you know what you're doing. In fact, there's actually nothing stopping you from doing this today with Taffy 1.x. Does anyone have an opinion on this idea? Good, bad, or otherwise?

Lastly, I'll say that I think the 2.0 release will be as small as possible. Heck, I may even do 2.0 as JUST removing deprecated functionality, and then plan any new changes for 2.1.

Looking forward to your feedback!

Adam

[Dave Shuck]

Are you taking suggestions on other items as well? 

Would you consider adding another custom attribute to <cfcomponent/> tags in resources?  If so, I'd love to see less boilerplate for DI by adding something like exists in the Mach-II framework.  Where I want to inject FooService and BarService, I could declare the following:

<cfcomponent extends="taffy.core.resource" taffy:uri="/foos" taffy:depends="FooService,BarService">

By declaring this, the methods getFooService() and getBarService() would then be available in the resource instance.  I would be happy to help contribute that if you would like.

[Adam Tuttle]

What if I were to meet you half way?

property name="fooService";
property name="barService";
 
What if I told you this was already included? ;)

Adam

Dave Shuck

April 17, 2013 4:04 PM

--
You received this message because you are subscribed to the Google Groups "Taffy Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to taffy-users...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Adam Tuttle

April 16, 2013 12:20 PM

I think the time has come to start working on Taffy 2.0. The current feature set seems to be stable and sufficient and bugs are few and far between.

Two things that I'd really like to address in 2.0:

• Get rid of everything that's been deprecated to date. Not an insignificant amount of code.
  
• Refresh the dashboard.
• Ultimately I'd love it if this were to use something like Swagger, and I'll look into it, but falling short of that, I may just try to make it less ugly.
• If going with the "less ugly" approach, Bootstrap would be a consideration, but I'd really rather not include a bunch of bootstrap files in the Taffy repo. This begs the question: Do you ever use the Taffy dashboard when you don't have an internet connection? It'd work to include Bootstrap stuff from a CDN, but only if you're online.

Something else that's been on my mind lately is abandoning the custom function names I created in Application.cfc for the traditional "onApplicationStart" and "onRequestStart". Doing so would require that you remember to include "super.onApplicationStart();" in your Application.cfc, and to do it at the right point in your implementation, which is a con. The matching pro is that everyone is familiar with these methods and it feels more natural, and would probably also be easier to remember the method names (if you have trouble remembering them, currently). It also gives you more control, if you know what you're doing. In fact, there's actually nothing stopping you from doing this today with Taffy 1.x. Does anyone have an opinion on this idea? Good, bad, or otherwise?

Lastly, I'll say that I think the 2.0 release will be as small as possible. Heck, I may even do 2.0 as JUST removing deprecated functionality, and then plan any new changes for 2.1.

Looking forward to your feedback!

Adam

--
You received this message because you are subscribed to the Google Groups "Taffy Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to taffy-users...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Matt Gersting]

I could be talking a little out my butt here, but I think you may be able to do that with the existing taffy:aopBean property that was added in 1.1.  I don't think we ever got around to documenting it fully, but here's the pull request:

https://github.com/atuttle/Taffy/pull/46

Basically, what I do is init ColdSpring (or whatever DI you're), then pass it in as the beanFactory in the configureTaffy() method.  To let Taffy know not to load the normal CFC, on your endpoint component you can either use taffy:aopBean or taffy_aopBean (depending on whether your in tag or script mode, if I recall) and set it to the name of the bean in ColdSpring. In the ColdSpring XML you could have load up any dependencies you want.