Hi group. I wanted to start a fire question here. As you know 3.5 is way on it's way and pretty much ready for beta cut. However, I want to plan not only for 3.5 buy for further versions.
So the questions are:
what do you want to see in the core?
What do you want to see out of the core?
Luis
IN:
i know this would probably be better suited for a module but just throwing it out there.
OUT:
Jeremy R. DeYoung
Phone:615.261.8201
RantsFromAMadMan.com
A file Uploader Interface with providers for Local file system, RAM,
S3, Dropbox and any other storage engine.
Thx
AL
I’d like a coldbox file uploader too. Especially one I could run post upload actions on and give user feedback about those actions vs what cf gives me now.
Some cool standard dialog box stuff would great rather than writing my own cfwindows.
As an addition to the core (or possibly a plugin/extension) I'd be a
fan of seeing a coldbox integrated validation library
(ValidationBox?). It's just one of those things that needs to be done
but is boring to do by hand. I love the way CB's configuration works,
particularly the way settings can be injected into objects easily. If
there a coldboxy way of dealing with validation the same way I'd
definitely use it. I've had a look at things like ValidateThis in the
past, but I tend to shy away from implementing several different
frameworks. I think that's the best part about CB - having all the
necessary tools in one place, and having them *documented* in the one
place.
Secondly, and this is a minor convenience thing, it'd be nice to have
the CacheBox monitor display the full object string (or at least
longer object strings) when you are picking through to see what's
happening. I use a session/locale string as a suffix so my cached
views look like this:
cbox_view-:layoutsnippets/
template_header_en_au_c2256851-90a8-3e99-3eebf4b1482af0c2
Unfortunately, the cache monitor only shows the first 44 characters,
so I get a list of very similar looking entries, all with the same
prefix .
cbox_view-:layoutsnippets/template_heade...
You can hover over to see the full string, but it's a slow way to find
the one you're after. I'd be quite happy for it to wrap in the list.
hyrule was core and it was voted out.
BTW hyrule is probably the most used feature of pre 3.0 that I use.
Not voted out but removed as there was no direction on enhancing it or evaluating it partially because I had no time for it.
I do have this in the backburner that should make itself present. We had a project called form daddy that helped with validation and form creation.
But I agree server side and orm entity validation is something that we need
Bean validation is part of hibernate tools too so might be interesting to look at it also for concepts and ideas.
Here is a ignorance question. Does hyrule work with non orm entities ?
Yes, I use it all the time with them as well. As long as accessors=‘true’ it will work.
Hibernate tools? I’d like to do my validation inside a bean.
I always find context-based form validation the most time consuming to implement. When I do bean validation it’s with the assumption that I’ve got all of the information I need, rather than a partial set.
Debatable subject I’m sure but I’d love to see the ability to manage views as CFCs.
I’m not a fan of Custom Tags ( before it’s suggested 
) & the idea of CFC based viewlets really appeals to me for the following reasons:-
Cheers,
James
Can you explain more on the CFC based viewlets? Personally cfm templates should be for views and CFC for everything else.
Unless you got something in your head that I am not thinking about, cause I just don’t see how a CFC viewlet would be beneficial.
I’d like the ability to define a list of accepted RC variables for my actions. ColdBox would ignore params that are unknown and serve more responses from the cache.
Use Case:
A specific action only uses an RC.CATS variable. A url could be: http://domain.com/foobar/cats/too-many or http://domain.com/foobar?cats=too-many. However, if someone hits http://domain.com/foobar?cats=too-many&dogs=none this appears to be a unique request to ColdBox despite the fact that the code ignores the RC.DOGS param that is created. Allowing the definition of a “known param list” or “acceptable param list” would help ensure malformed requests don’t create wasted processing.
What my API does…
For an API I developed, I created this process but it requires the handler to execute and I use a BaseHandler’s arroundHandler() method to perform this processing. I essentially remove unknown params, order the clean list and hash the result to create a unique cache key. This ensured that regardless of the order or number of “junk” params passed, the API would consistently serve responses from the cache. After completing the development of the API I realized I could benefit from the same logic anywhere in the application. Unless this is in the core, the tricky part becomes identifying the target handler/action when the onRequestCapture event is executed.
Thanks,
Aaron
+1
Nolan
As a slight alternative to that suggestion (not that I’m discounting it) while we’re talking about views:
After some recent adventures with Django I really liked their templating approach to views. So the view layer is made up of static HTML files with place holders within them.
{person.firstname} {person.lastname}
You then pass those as named arguments into the view rendering function along with the view.
The reason that I really liked this approach, was that firstly the templating language can be platform agnostic, so I could take my same views and drop them into any platform and they can be used. This loose coupling is very cool!
It also advocates abstraction of logic into the controller / model rather than it being in the view layer, as only simple logic can be carried out in a templating syntax.
Robert
Robert,
I’ve been thinking about that for a while. Especially, since we’re starting to hand off a lot of the templating work to the client via JavaScript. I decided to not use mustache style templating, and just send down my CFML snippets to the client and use the pound-signs instead of curley braces to mark start/end of template keys. I did not want to slow down my views by doing string replacements.
However, my thought process was unique to my needs. I do not need to share my views with other server-side languages.
-A
More ORM related stuff would be great.
I’m a big fan of the virtual entity service, but I have had a couple of ideas for enhancements too.
Richer Relationships.
One of the things I really love about both Rails and Django is the fact that relationships on entities aren’t just dumb collections (structs / arrays) but rich searchable query sets.
So if I have an instance of ‘foo’ I can do 'foo.bars.findWhere(name=‘Robert’) and it’ll give me all the bars related to that particular foo who’s name is Robert.
You can obviously achieve such things with the build in ORM entities and services, but I love the accessibility of the collection itself being rich.
On another note, I will +1 on some form of validation framework. I user ValidateThis for all our projects, and it’s simple enough to integrate but it would be nice to have something baked into the core for sure.
Robert
Hi Aaron,
That sounds like a nice approach to things. I agree that with the growth of Javascript front event templating is becoming a much more common practice.
I was reading a few threads on templating recently with regards to email content, someone was building a app where they wanted users to have control over the content of emails, and moutache was one of the discussed options.
I think people were concerned about the string replacement performance issues.
However, I wonder if anyone has done any benchmarking on just how efficient / inefficient it is?
Robert