Needs for 4.5

[Luis Majano]

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

Sent from my iPhone

[Jeremy R DeYoung]

IN:

 - would be nifty to have a built in cms editor

 - as well as a built in multi-file uploader

i know this would probably be better suited for a module but just throwing it out there.

OUT:

 - nothing really comes to mind

- - - - - - - - - - - - - - - - - 
Jeremy R. DeYoung 
Phone:615.261.8201 
 
RantsFromAMadMan.com 

--
You received this message because you are subscribed to the Google Groups "ColdBox Platform" group.
To post to this group, send email to col...@googlegroups.com
To unsubscribe from this group, send email to coldbox-u...@googlegroups.com
For more options, visit this group at http://groups-beta.google.com/group/coldbox
For News, visit http://blog.coldbox.org
For Documentation, visit http://wiki.coldbox.org

[al]

A file Uploader Interface with providers for Local file system, RAM,
S3, Dropbox and any other storage engine.

Thx
AL

[Jonathan Perret]

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. 

[oobi]

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.

[Andrew Scott]

hyrule was core and it was voted out.

BTW hyrule is probably the most used feature of pre 3.0 that I use.

--
You received this message because you are subscribed to the Google Groups "ColdBox Platform" group.
To post to this group, send email to col...@googlegroups.com
To unsubscribe from this group, send email to coldbox-u...@googlegroups.com
For more options, visit this group at http://groups-beta.google.com/group/coldbox
For News, visit http://blog.coldbox.org
For Documentation, visit http://wiki.coldbox.org

--

Regards,

Andrew Scott

WebSite: http://www.andyscott.id.au/

Google+: http://plus.google.com/108193156965451149543

[Luis Majano]

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

Sent from my iPhone

[Luis Majano]

Bean validation is part of hibernate tools too so might be interesting to look at it also for concepts and ideas. 

Sent from my iPhone

On Oct 1, 2011, at 7:39 PM, Andrew Scott <and...@andyscott.id.au> wrote:

[Luis Majano]

Here is a ignorance question. Does hyrule work with non orm entities ?

Sent from my iPhone

On Oct 1, 2011, at 7:39 PM, Andrew Scott <and...@andyscott.id.au> wrote:

[Andrew Scott]

Yes, I use it all the time with them as well. As long as accessors='true' it will work.

-- 

Regards,

Andrew Scott

WebSite: http://www.andyscott.id.au/

Google+: http://plus.google.com/108193156965451149543

[Jonathan Perret]

Hibernate tools? I'd like to do my validation inside a bean.

[Chris Carey]

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.

[James Buckingham]

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:-

- The passing of view data can be controlled through passing arguments = Leveraged support for self-contained viewlets
- Unit Testing of Views in insolation from Events could be done. NOTE - don't know if that's currently possible by the way :-).
- Self-documenting is added by using CFCs
- A single file containing all the view data related to a Handler would be great to work with compared to a folder full of separate .cfm files.

Cheers,
James

[Andrew Scott]

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.

-- 

Regards,

Andrew Scott

WebSite: http://www.andyscott.id.au/

Google+: http://plus.google.com/108193156965451149543

--

[Aaron Greenlee]

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

[Nolan Dubeau]

+1

Nolan

[Rawlins]

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

[Aaron Greenlee]

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

[Rawlins]

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

[Rawlins]

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

[James Buckingham]

Hey Andrew

"Can you explain more on the CFC based viewlets? Personally cfm templates should be for views and CFC for everything else."

Yeah .cfm being the convential way of doing MVC views. Referencing the ColdBox Doc a Viewlets can be defined as:-

"....a self sufficient view. A view that can live on its own, its data is pre-fetched and can just be renderer as is."
http://ortus.svnrepository.com/coldbox/trac.cgi/wiki/cbLayoutsViewsGuide#Viewlets

My argument is, what's the difference between these and how a CFC works in the model? ColdBox has Plugin support I know but what I'm talking about is taking something like a JS DataGrid, encapsulating that in a Viewlet CFC and giving a user Coldbox support for something like :-

event.setView(jsData.displayByQuery(myQuery)).

With ColdBox looking for a View CFC of the name jsData.

"I just don't see how a CFC viewlet would be beneficial."

Aside from the points I mentioned in the previous post?

It's maybe not beneficial over what's there just now in terms of View management but it could be looked at as an alternative convention-based approach.

Taking the theory a step further. Normally you're handler / view folder structure would look something like this:-

Handlers
-- handler1
-- handler2
Views
-- handler1
--- view1
--- view2
--- view3
-- handler2
--- view1
--- view2
etc.

A View CFC approach could see things slimmed down into a structure like this...

Handlers
-- handler1
-- handler2
Views
- handler1.cfc
- handler2.cfc

With each view .cfc matching a handler and containing methods view1,view2 etc.

I know HTML is a bit of a Taboo when it comes to CFCs but seeing how loose / open to abuse our project's views currently sit I could see this as a benefit in controlling what's actually passed in and used in the views.

Cheers,
James

[Nolan Dubeau]

Hi guys,

there's some serious dialogue going on for a some in-depth needs for 4.5. would it be valuable to create some sub-threads so larger discussions around a particular "need" can remain in their own thread? Just a thought because I don't want to hijack this topic

i'm going to sneak this "need" into this thread ...

Perhaps there is already a way to accomplish this....

In routes, and in handlers you can set method security to protect the HTTP actions that execute an event.  It would be great if there is a framework method that can be accessed higher up in the request scope to determine if the executing event validates against the allowedMethod rules.  Its is my understanding that currently this can only be trapped in Main.cfc onError() by evaluating the type of error.  It would be great to be able access this within a preProcess() or aroundHandler() before it gets far down the chain.

Thanks.

Nolan

[Andrew Scott]

Sorry James, I don't see the benefit..

-- 

Regards,

Andrew Scott

WebSite: http://www.andyscott.id.au/

Google+: http://plus.google.com/108193156965451149543

Cheers,
James

--

[Andrew Scott]

No it can also be part of the security interceptor, but I like where you are leading. There is attributes that can be applied to events that can be sort of used this way. But if you are referring to role based security then this will need to be handled by the security interception and how it works to your rules.

Is that what you were meaning or am I off base?

-- 

Regards,

Andrew Scott

WebSite: http://www.andyscott.id.au/

Google+: http://plus.google.com/108193156965451149543

[Nolan Dubeau]

Hi Andrew,

I agree that it could be added to the security interceptor, but it may be valuable to evaluate the invalid request at the handler level (in an aroundHandler) if the app wasn't using the security interceptor.

I don't think this relates to role based security, but rather route security and method security.

i.e  in routes:

addRoute(pattern="/users/:userid",handler="User",

action={

GET = "getUser",

PUT  = "updateUser"

});

and in User.cfc handler:

// HTTP Security

this.allowedMethods = {getUser='GET',createUser='POST',updateUser='PUT'};

so, essentially i'd like to determine that a POST is trying to be executed on a route that only allows GET's and handle accordingly further up in the request as opposed to an error being thrown and have to handle in onError()

Thanks.

Nolan

[Andrew Scott]

Out of curiosity what type of error is thrown?

-- 

Regards,

Andrew Scott

WebSite: http://www.andyscott.id.au/

Google+: http://plus.google.com/108193156965451149543

[Nolan Dubeau]

 <h3>Application Execution Exception</h3>

     

    <strong>Error Type: </strong> SES.405 : 405<br />

     

        <strong>Error Messages:</strong>

        Invalid HTTP method: GET<br />

        The HTTP method used: GET is not valid for the current executing resource. Valid methods are: {POST={createUser}}

 

    </div>







[Don Q]

This will eventually get lost in the sea of ideas, but I would really
love to see more capabilities in the BaseORMService.

Namely, more with criteria queries, dealing with projections and group
by - I'm a big fan of this.

[Jason Durham]

I suggest expanding Forgebox. The framework core is already pretty feature rich. 

Jason Durham

[Aaron Greenlee]

I agree with Nolan.

This may help us? http://coldbox.uservoice.com/

[Luis Majano]

On this topic of views, this already exists with the concept of renderView(args={}) and passing name value pairs that are evaluated in the views.  So you could technically apply #args.username# or #args.name# and call your views much like how you call a method.

Luis F. Majano

CEO

Ortus Solutions, Corp

www.ortussolutions.com

ColdBox Platform: http://www.coldbox.org

Linked In: http://www.linkedin.com/pub/3/731/483

Blog: http://www.luismajano.com

IECFUG Manager: http://www.iecfug.com

Social: twitter.com/lmajano facebook.com/lmajano

--

[Luis Majano]

On viewless you have the olds docs link, this is the new docs: http://wiki.coldbox.org/wiki/Layouts-Views.cfm#Viewlets_(Portable_Events) 

You can create viewlets as CFC event handlers now in 3.0

Luis F. Majano

CEO

Ortus Solutions, Corp

www.ortussolutions.com

ColdBox Platform: http://www.coldbox.org

Linked In: http://www.linkedin.com/pub/3/731/483

Blog: http://www.luismajano.com

IECFUG Manager: http://www.iecfug.com

Social: twitter.com/lmajano facebook.com/lmajano

--

[Luis Majano]

Nolan, this is a little contradictory also because you have this:

addRoute(pattern="/users/:userid",handler="User",

action={

GET = "getUser",

PUT  = "updateUser"

});

Which splits the routes on the http verbs, so if you add the "allowedMethods" into the User handler, that exception will not be thrown at the handler level but the route level.  So in reality since your route defines the HTTP verbs, then only those work, then ones local to the handler are never reached.

Luis F. Majano

CEO

Ortus Solutions, Corp

www.ortussolutions.com

ColdBox Platform: http://www.coldbox.org

Linked In: http://www.linkedin.com/pub/3/731/483

Blog: http://www.luismajano.com

IECFUG Manager: http://www.iecfug.com

Social: twitter.com/lmajano facebook.com/lmajano

[Luis Majano]

>Namely, more with criteria queries, dealing with projections and group
by - I'm a big fan of this.

I totally agree Don, I think what we have in the base and virtual services is a great place to start.  We can just get better and improve this more.  I have been using criterias and projects and there is definitely room for improvement.  I am thinking of extending this to a criteria DSL language so you don't have to deal with some convoluted hibernate methods.

Maybe we can create a new thread about all the ideas and then come up with a roadmap for them.

Luis F. Majano

CEO

Ortus Solutions, Corp

www.ortussolutions.com

ColdBox Platform: http://www.coldbox.org

Linked In: http://www.linkedin.com/pub/3/731/483

Blog: http://www.luismajano.com

IECFUG Manager: http://www.iecfug.com

Social: twitter.com/lmajano facebook.com/lmajano

[Luis Majano]

Aaron, I didn't quite get your enhancement, are you saying create constraints for event caching?  Maybe like:

function show(event,rc,orc) cache="true" cacheTimeout="50" cacheAllowedRC="cats,hello"{

}

And event caching permutations are only allowed on the existence of CATS OR HELLO or CATS AND HELLO?

Luis F. Majano

CEO

Ortus Solutions, Corp

www.ortussolutions.com

ColdBox Platform: http://www.coldbox.org

Linked In: http://www.linkedin.com/pub/3/731/483

Blog: http://www.luismajano.com

IECFUG Manager: http://www.iecfug.com

Social: twitter.com/lmajano facebook.com/lmajano

[Luis Majano]

ForgeBox additions should definitely be something we all contribute to also.  I am thinking of maybe taking all the core ColdBox debugger panels, timers, etc and converting them into a module and removing from the core.  Thoughts?

Luis F. Majano

CEO

Ortus Solutions, Corp

www.ortussolutions.com

ColdBox Platform: http://www.coldbox.org

Linked In: http://www.linkedin.com/pub/3/731/483

Blog: http://www.luismajano.com

IECFUG Manager: http://www.iecfug.com

Social: twitter.com/lmajano facebook.com/lmajano

[Nolan Dubeau]

Hi Luis,

Thanks for the info.  Regardless of which is used though,  is there a framework method that can be accessed to determine if the verb being used on a method is invalid?  If not this would be a great enhancement.

Nolan

[Andrew Scott]

I am still wondering if it would be better to have this caught by an onInvalidEvent?

[Nolan Dubeau]

Hi Luis,

I've had a few conversations with Aaron about this so I'll add my two cents.  Correct me if i'm wrong please Aaron.  

If it were implemented as an attribute i would say it should be called  ....  allowedRC="cats,hello".  The cache is a secondary part that is handled at the end of the request  (in Aaron's case).   The idea would be that the "allowedRC" variables are the only vars allowed in that method, and all others should be stripped out of the RC  (....this is just my assumption...aaron should clarify).  

The point he makes around ordering the vars alphabetically is also important and perhaps is another feature or a setting that can be added.  this can be particularly important when hashing and caching the request.

Thanks.

Nolan

[Nolan Dubeau]

I think it's too far down the chain at that point.

i'm thinking of this from a REST API standpoint...

In the same way I would validate API keys or authorization credentials In my security interceptor I would also want to be able to call a method like  event.isHTTPmethodAllowed() or something like that to determine that someone is trying to to a POST on a GET method and then send back the appropriate error response / override the event.

Nolan

[Luis Majano]

Interesting, so how would you determine it, from the routes or from the event metadata?  I guess I don't quite see it yet.

Luis F. Majano

CEO

Ortus Solutions, Corp

www.ortussolutions.com

ColdBox Platform: http://www.coldbox.org

Linked In: http://www.linkedin.com/pub/3/731/483

Blog: http://www.luismajano.com

IECFUG Manager: http://www.iecfug.com

Social: twitter.com/lmajano facebook.com/lmajano

[Nolan Dubeau]

Hmmm.  that's a great question.

My gut tells me that it should be at the event metadata level.  routing should just handle routing.  this.allowedMethods={} is more for the security of those methods so if you evaluating event.isHTTPmethodAllowed() or event.isValidHTTPMethod()  then it should be looking at the meta data that defines those rules.

I'm open to discussion though.  Is there functionality overlap with both of the code snippets I outlined below? Or rather is there a need to define a rule within the route if there is also a rule at the handler level?

Thanks.

Nolan

[Aaron Greenlee]

Yes. Except, I would go so far as to not allow the RC variables not in the list. 

function show(event,rc,orc) cache="true" cacheTimeout="50" acceptedRC="cats,hello" { return; }

So, if cats and/or hello exist in the URL/FORM scope they would be copied into RC on requestCapture. However, if someone provides "dogs" in the URL/FORM scope they will be ignored completely.

[Luis Majano]

Now are we talking about event caching or any event?

Sent from my iPhone

--

[Andrew Scott]

Wouldn't RC get confused with Request Context?

--

You received this message because you are subscribed to the Google Groups "ColdBox Platform" group.
To post to this group, send email to col...@googlegroups.com
To unsubscribe from this group, send email to coldbox-u...@googlegroups.com
For more options, visit this group at http://groups-beta.google.com/group/coldbox
For News, visit http://blog.coldbox.org
For Documentation, visit http://wiki.coldbox.org

[Aaron Greenlee]

Both. If this setting is applied ColdBox will only "import" known and accepted variables into the Request Context (RC). This serves to ensure caching can't be messed up by junk variables and provides some documentation about the expectations of the handler/action.

[Andrew Scott]

kk, now I see the benefit of this.

Would that also mean that the cache would re-get these or that is just wishful thinking?

-- 

Regards,

Andrew Scott

WebSite: http://www.andyscott.id.au/

Google+: http://plus.google.com/108193156965451149543

On Thu, Oct 6, 2011 at 4:29 AM, Aaron Greenlee <aarong...@gmail.com> wrote:

Both. If this setting is applied ColdBox will only "import" known and accepted variables into the Request Context (RC). This serves to ensure caching can't be messed up by junk variables and provides some documentation about the expectations of the handler/action.

--

[Aaron Greenlee]

Andrew, Not sure what you mean by re-get. If the output of the event is cached ColdBox would simply flush that to the output stream and avoid any processing of the Handler/Action.

[Andrew Scott]

Yes, but any variables will be cached as well. That is what I meant there...

Also another addition to 4.5 on a side note would be this.

event.RenderNoLayout();

I know you can do it in the view, but if I have the view as the same name as the handler it sort of defeats the purpose of having to retell the framework the name of the view to use. Or is this already capable of being done?

-- 

Regards,

Andrew Scott

WebSite: http://www.andyscott.id.au/

Google+: http://plus.google.com/108193156965451149543

On Thu, Oct 6, 2011 at 4:50 AM, Aaron Greenlee <aarong...@gmail.com> wrote:

Andrew, Not sure what you mean by re-get. If the output of the event is cached ColdBox would simply flush that to the output stream and avoid any processing of the Handler/Action.

--

[Luis Majano]

Ccan you expand on this layout thing I didn't get it 

Sent from my iPhone

[Andrew Scott]

At the moment if we write code like this

public function testHandler() {

}

We can have a view called testHandler.

If we want this handler to have no layout, we are forced to write

public function testHandler() {

  event.setView(name="testHandler', layout=false);

}

my question is why can't we just type

public function testHandler() {

   noLayoutRender();

}

-- 

Regards,

Andrew Scott

WebSite: http://www.andyscott.id.au/

Google+: http://plus.google.com/108193156965451149543

[Malik Robinson]

Yah, I'd like to be able to do that too.

Malik

>> WebSite: http:// <http://www.andyscott.id.au/>www.andyscott.id.au/
>> Google+: <http://plus.google.com/108193156965451149543>

>> http://plus.google.com/108193156965451149543
>>
>>
>>
>> On Thu, Oct 6, 2011 at 4:50 AM, Aaron Greenlee < <aarong...@gmail.com>
>> aarong...@gmail.com> wrote:
>>
>>> Andrew, Not sure what you mean by re-get. If the output of the event is
>>> cached ColdBox would simply flush that to the output stream and avoid any
>>> processing of the Handler/Action.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "ColdBox Platform" group.
>>> To post to this group, send email to <col...@googlegroups.com>
>>> col...@googlegroups.com
>>> To unsubscribe from this group, send email to
>>> <coldbox-u...@googlegroups.com>
>>> coldbox-u...@googlegroups.com
>>> For more options, visit this group at
>>> <http://groups-beta.google.com/group/coldbox>
>>> http://groups-beta.google.com/group/coldbox

>>> For News, visit <http://blog.coldbox.org>http://blog.coldbox.org
>>> For Documentation, visit <http://wiki.coldbox.org>http://wiki.coldbox.org

>>>
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ColdBox Platform" group.
>> To post to this group, send email to <col...@googlegroups.com>

>> col...@googlegroups.com
>> To unsubscribe from this group, send email to

>> <coldbox-u...@googlegroups.com>coldbox-u...@googlegroups.com

>> For more options, visit this group at
>> <http://groups-beta.google.com/group/coldbox>
>> http://groups-beta.google.com/group/coldbox

>> For News, visit <http://blog.coldbox.org>http://blog.coldbox.org
>> For Documentation, visit <http://wiki.coldbox.org>http://wiki.coldbox.org

>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ColdBox Platform" group.
>> To post to this group, send email to col...@googlegroups.com
>> To unsubscribe from this group, send email to
>> coldbox-u...@googlegroups.com
>> For more options, visit this group at
>> http://groups-beta.google.com/group/coldbox
>> For News, visit http://blog.coldbox.org
>> For Documentation, visit http://wiki.coldbox.org
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ColdBox Platform" group.
> To post to this group, send email to col...@googlegroups.com
> To unsubscribe from this group, send email to
> coldbox-u...@googlegroups.com
> For more options, visit this group at
> http://groups-beta.google.com/group/coldbox
> For News, visit http://blog.coldbox.org
> For Documentation, visit http://wiki.coldbox.org
>

--
Sent from my mobile device

[Luis Majano]

Ask and you shall receive: event.noLayout() is now online

Luis F. Majano

CEO

Ortus Solutions, Corp

www.ortussolutions.com

ColdBox Platform: http://www.coldbox.org

Linked In: http://www.linkedin.com/pub/3/731/483

Blog: http://www.luismajano.com

IECFUG Manager: http://www.iecfug.com

Social: twitter.com/lmajano facebook.com/lmajano

[Brad Wood]

For what it's worth, I modified setView() in my request context decorator to default the noLayout argument to getValue("nolayout",false).

 

That allows me to override the layout adhoc anywhere on my site at runtime by adding ?noLayout=true to the URL.  Especially useful if I want to be able to stick a stand-alone event into an iframe or a popup and not have the layout right then.  Not quite what you guys were talking about, but it's along the same vein and might make a nice addition.  Of course, if only kicks in if you have an event.setView() call.  There might be a "higher" place to implement that so it always works.

 

~Brad

 

 

----- Original Message -----

[Dan Vega]

Just an FYI because I saw someone mention it earlier. Hyrule can work with contexts so you don't have to validate an entire bean.

validator.validate(user,"password,passwordConfirm");

I think its a really strong core project now and the only reason more people are not using it is because it lacks documentation + tutorials. I am extremely tied up in side work right now but when I get a breather I will focus on that.

[Luis Majano]

Dan,

Maybe we need to talk then to maybe see how we can make it part of the core with some updates we have in mind, and I will document it.

Luis F. Majano

CEO

Ortus Solutions, Corp

www.ortussolutions.com

ColdBox Platform: http://www.coldbox.org

Linked In: http://www.linkedin.com/pub/3/731/483

Blog: http://www.luismajano.com

IECFUG Manager: http://www.iecfug.com

Social: twitter.com/lmajano facebook.com/lmajano

--

[Dan Vega]

I am still with a lot of the people on here in that I don't think it should be part of the core. I would like to make it really easy to use in ColdBox though. We should def talk and figure out what is the best way to accomplish this.

[Robert Rawlins]

My thoughts on this, whilst late to the conversation:

I think out of the box validation within ColdBox would be awesome, without doubt. I mean, the grand vision has always been to build a full stack, right? Validation is something that is so fundamental in day-to-day development that in my eyes, it becomes an integral part of a full stack.

However, I can also appreciate that people like flexibility, and the benefits of using a framework they're familiar with.

So, what about some form of adaptor pattern. Where we have a validation API, baked into the core of ColdBox, where the underlying library could be switched out, HyRule, ValidateThis etc etc.

This would allow ColdBox to deliver validation as part of it's core library, with functionality built right into the handlers but remain flexible for developers who want to use their library of choice.

Further to that, it allows us to path-find what people want, if we find a large number of users using the HyRule adaptor then we might decide to consume HyRule into the CB core development, but as the default adaptor, rather than the 'only' way of doing things.

On 28 Oct 2011, at 14:30, Dan Vega wrote:

I am still with a lot of the people on here in that I don't think it should be part of the core. I would like to make it really easy to use in ColdBox though. We should def talk and figure out what is the best way to accomplish this.

[Dan Vega]

Exactly! Great points. Plus I will be honest I haven't got a ton of feedback on Hyrule... maybe its a huge pile of junk and nobody likes it? I don't know a ton about validateThis so I am not sure how hard it will be to create an adapter that we can both use.

[Robert Rawlins]

Yeah, I think it could certainly be a potential approach.

I'm sure it has plenty of challenges that would have to be overcome, however, we would only need to provide the basic usage at an adaptor level, just access to the 'validate()' method and perhaps a normalised results object.

I don't know. Probably worth exploring in more detail with a few use cases.

On 28 Oct 2011, at 14:48, Dan Vega wrote:

Exactly! Great points. Plus I will be honest I haven't got a ton of feedback on Hyrule... maybe its a huge pile of junk and nobody likes it? I don't know a ton about validateThis so I am not sure how hard it will be to create an adapter that we can both use.

[Ben Dalton]

Dan,

I'm using hyrule and like it. I dropped it in, added some annotations and it worked. Although I did have to change the \ to / in a few places. If you are writing paths, with cf always use the / since it works on both Linux and windows installs (acf automatically uses the native path delimiter if you use /)

On Oct 28, 2011, at 9:48 AM, Dan Vega <dan...@gmail.com> wrote:

Exactly! Great points. Plus I will be honest I haven't got a ton of feedback on Hyrule... maybe its a huge pile of junk and nobody likes it? I don't know a ton about validateThis so I am not sure how hard it will be to create an adapter that we can both use.

--

[Andrew Scott]

Love Hyrule, the only thing I dont like is that you cant override validate in your own service while extending the main hyrule core. It refuses to work.

On Sat, Oct 29, 2011 at 12:48 AM, Dan Vega <dan...@gmail.com> wrote:

Exactly! Great points. Plus I will be honest I haven't got a ton of feedback on Hyrule... maybe its a huge pile of junk and nobody likes it? I don't know a ton about validateThis so I am not sure how hard it will be to create an adapter that we can both use.

--

You received this message because you are subscribed to the Google Groups "ColdBox Platform" group.
To post to this group, send email to col...@googlegroups.com
To unsubscribe from this group, send email to coldbox-u...@googlegroups.com
For more options, visit this group at http://groups-beta.google.com/group/coldbox
For News, visit http://blog.coldbox.org
For Documentation, visit http://wiki.coldbox.org