Few contributions I want to make

[Antonio Salazar Cardozo]

There are a variety things in the OpenStudy toolbox that I'd love to move into Lift as I have time, but I wanted some feedback on a few of them:

 - We currently have a submitFormToIframe function that makes it so an ajax form with a file upload component can upload via “ajax” transparently to the developer and the user. I'd like to move that into liftAjax.js and, ideally, have some code that will automatically convert any generated forms with an input type file into iframed, fully functional ajax forms from a developer's perspective. Is this something people would like to see in Lift? As a user of the framework, my goal would be to make this completely transparent*.

 - Add a LiftRules.noCometSessionCmd for handling server reloads. This would be an extension of LiftRules.noCometSessionPage that would default to using noCometSessionPage for a redirect, but could be overridable to produce an arbitrary JsCmd. That seems the best way to go for backwards compatibility, though it makes me nervous that if you changed noCometSessionCmd, noCometSessionPage would be ignored. Thoughts?

 - Potentially make it so that setting LiftRules.noCometSessionPage/Cmd would automatically turn off LiftRules.redirectAjaxOnSessionLoss, or something of the sort. It seems counterintuitive on its face (though not so with a deeper understanding of the internals) that redirectAjaxOnSessionLoss has to be turned off for noCometSession* to take effect. Definitely looking for some feedback on that front. Notably, it may be enough to make it so that redirectAjaxOnSessionLoss only matters if you're doing an ajax request. I think right now both ajax and comet requests pay attention to that setting, and if we made comet requests ignore it we may be able to mitigate the issue without any further complications.

 - The addition of an xhr_? function to Req. This would return true iff the request has an X-Requested-With header equal to XMLHttpRequest (most client-side frameworks set this on all ajax requests). We've used this in the past to include/exclude layouts based on whether a page was requested via ajax or not. Maybe ajax_? would be a better name?

 - Equivalents for SHtml inputs that just provide a name for various types of fields. We use this in conjunction with knockout.js to bind input names client-side for Lift form management sent via JSON instead of as pure HTML. We have nameForStringField((s:String) => handler), nameForFileUploadField((fph:FileParamHolder) => handler), and nameForSubmitButton(() => JsCmd return). This may be one of those things that is better provided alongside Lift rather than as part of Lift proper, but I wanted to hear what people thought about it.

So, thoughts, feedback, things you definitely think shouldn't be in there? Let me know!

Thanks,

Antonio

* - notably, I don't intend on including any progress indicator stuff. I just want ajax forms that have file upload components to behave exactly the same as those that have no such components with no further developer effort.

[David Pollak]

All this looks great to me!

--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

--

Visi.Pro, Cloud Computing for the Rest of Us http://visi.pro

Lift, the simply functional web framework http://liftweb.net

Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im

[Diego Medina]

Hi Antonio,

They all would be great additions to Lift imho, some small comments below:

On Fri, Apr 6, 2012 at 5:44 PM, Antonio Salazar Cardozo
<savedf...@gmail.com> wrote:
> There are a variety things in the OpenStudy toolbox that I'd love to move
> into Lift as I have time, but I wanted some feedback on a few of them:
>
>  - We currently have a submitFormToIframe function that makes it so an ajax
> form with a file upload component can upload via “ajax” transparently to the
> developer and the user. I'd like to move that into liftAjax.js and, ideally,
> have some code that will automatically convert any generated forms with an
> input type file into iframed, fully functional ajax forms from a developer's
> perspective. Is this something people would like to see in Lift?

More and more often people ask how to do an ajax upload in Lift, so
having a builtin way would be great.

>As a user
> of the framework, my goal would be to make this completely transparent*.
>  - Add a LiftRules.noCometSessionCmd for handling server reloads. This would
> be an extension of LiftRules.noCometSessionPage that would default to using
> noCometSessionPage for a redirect, but could be overridable to produce an
> arbitrary JsCmd. That seems the best way to go for backwards compatibility,
> though it makes me nervous that if you changed noCometSessionCmd,
> noCometSessionPage would be ignored. Thoughts?

I would think that if someone changes noCometSessionCmd, it is because
they know about it, so ignoring noCometSessionPage would be ok. Maybe
adding a warning on the api doc on both method would help too.

>  - Potentially make it so that setting LiftRules.noCometSessionPage/Cmd
> would automatically turn off LiftRules.redirectAjaxOnSessionLoss, or
> something of the sort. It seems counterintuitive on its face (though not so
> with a deeper understanding of the internals) that redirectAjaxOnSessionLoss
> has to be turned off for noCometSession* to take effect. Definitely looking
> for some feedback on that front. Notably, it may be enough to make it so
> that redirectAjaxOnSessionLoss only matters if you're doing an ajax request.
> I think right now both ajax and comet requests pay attention to that
> setting, and if we made comet requests ignore it we may be able to mitigate
> the issue without any further complications.

From the outside (as in I haven;t looked at redirectAjaxOnSessionLoss
yet), separating it makes sense. I wonder if there is any benefit in
having noCometSessionPage changed but keep redirectAjaxOnSessionLoss
as true.

>  - The addition of an xhr_? function to Req. This would return true iff the
> request has an X-Requested-With header equal to XMLHttpRequest (most
> client-side frameworks set this on all ajax requests). We've used this in
> the past to include/exclude layouts based on whether a page was requested
> via ajax or not. Maybe ajax_? would be a better name?

I'm ok with either name, but we do use ajax* on several places in Lift.

>  - Equivalents for SHtml inputs that just provide a name for various types
> of fields. We use this in conjunction with knockout.js to bind input names
> client-side for Lift form management sent via JSON instead of as pure HTML.
> We have nameForStringField((s:String) => handler),
> nameForFileUploadField((fph:FileParamHolder) => handler), and
> nameForSubmitButton(() => JsCmd return). This may be one of those things
> that is better provided alongside Lift rather than as part of Lift proper,
> but I wanted to hear what people thought about it.

Sounds interesting but I don't fully follow what it does, does it
change the way Lift generates names for forms?

>
> So, thoughts, feedback, things you definitely think shouldn't be in there?

I think you should add them all :) !

Thanks

Diego

> Let me know!
> Thanks,
> Antonio
>
> * - notably, I don't intend on including any progress indicator stuff. I
> just want ajax forms that have file upload components to behave exactly the
> same as those that have no such components with no further developer effort.
>

> --
> Lift, the simply functional web framework: http://liftweb.net
> Code: http://github.com/lift
> Discussion: http://groups.google.com/group/liftweb
> Stuck? Help us help you:
> https://www.assembla.com/wiki/show/liftweb/Posting_example_code

--
Diego Medina
Lift/Scala Developer
di...@fmpwizard.com
http://www.fmpwizard.com

[Mads Hartmann Jensen]

> - We currently have a submitFormToIframe function that makes it so an ajax form with a file upload component can upload via “ajax” transparently to the developer and the user. I'd like to move that into liftAjax.js and, ideally, have some code that will automatically convert any generated forms with an input type file into iframed, fully functional ajax forms from a developer's perspective. Is this something people would like to see in Lift? As a user of the framework, my goal would be to make this completely transparent*.

It might be nice to avoid the iframe and use the JavaScript FormData API when present (seems to work in Safari, Chrome, Firefox, haven't tried IE)

http://hacks.mozilla.org/2010/05/formdata-interface-coming-to-firefox/
http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#interface-formdata

> - Equivalents for SHtml inputs that just provide a name for various types of fields. We use this in conjunction with knockout.js to bind input names client-side for Lift form management sent via JSON instead of as pure HTML. We have nameForStringField((s:String) => handler), nameForFileUploadField((fph:FileParamHolder) => handler), and nameForSubmitButton(() => JsCmd return). This may be one of those things that is better provided alongside Lift rather than as part of Lift proper, but I wanted to hear what people thought about it.

I agree this would be nice. Maybe instead of returning a string return an object like

trait FormElement {
def name: String
def html: NodeSeq
}

[Antonio Salazar Cardozo]

On Friday, April 6, 2012 9:57:21 PM UTC-4, fmpwizard wrote:

Hi Antonio,

They all would be great additions to Lift imho, some small comments below:

 

On Fri, Apr 6, 2012 at 5:44 PM, Antonio Salazar Cardozo
<savedf...@gmail.com> wrote: 

>  - Add a LiftRules.noCometSessionCmd for handling server reloads. This would
> be an extension of LiftRules.noCometSessionPage that would default to using
> noCometSessionPage for a redirect, but could be overridable to produce an
> arbitrary JsCmd. That seems the best way to go for backwards compatibility,
> though it makes me nervous that if you changed noCometSessionCmd,
> noCometSessionPage would be ignored. Thoughts?

I would think that if someone changes noCometSessionCmd, it is because
they know about it, so ignoring noCometSessionPage would be ok. Maybe
adding a warning on the api doc on both method would help too.

Fair enough, will definitely mention this in the API docs.

 

>  - Potentially make it so that setting LiftRules.noCometSessionPage/Cmd
> would automatically turn off LiftRules.redirectAjaxOnSessionLoss, or
> something of the sort. It seems counterintuitive on its face (though not so
> with a deeper understanding of the internals) that redirectAjaxOnSessionLoss
> has to be turned off for noCometSession* to take effect. Definitely looking
> for some feedback on that front. Notably, it may be enough to make it so
> that redirectAjaxOnSessionLoss only matters if you're doing an ajax request.
> I think right now both ajax and comet requests pay attention to that
> setting, and if we made comet requests ignore it we may be able to mitigate
> the issue without any further complications.

From the outside (as in I haven;t looked at redirectAjaxOnSessionLoss
yet), separating it makes sense. I wonder if there is any benefit in
having noCometSessionPage changed but keep redirectAjaxOnSessionLoss
as true.

At the moment, there isn't. In the sense that the noCometSessionPage will never get hit if redirectAjaxOnSessionLoss is set. The other question is if we want to allow changing the ajax redirect (which currently is hardcoded to either the ajax request referrer (if present) or /) in LiftRules, and use this single unified setting both there and in the no comet session stuff?

 

>  - The addition of an xhr_? function to Req. This would return true iff the
> request has an X-Requested-With header equal to XMLHttpRequest (most
> client-side frameworks set this on all ajax requests). We've used this in
> the past to include/exclude layouts based on whether a page was requested
> via ajax or not. Maybe ajax_? would be a better name?

I'm ok with either name, but we do use ajax* on several places  in Lift.

Yep, that's why I thought ajax_? might be better. I'll probably stick to that.

 

>  - Equivalents for SHtml inputs that just provide a name for various types
> of fields. We use this in conjunction with knockout.js to bind input names
> client-side for Lift form management sent via JSON instead of as pure HTML.
> We have nameForStringField((s:String) => handler),
> nameForFileUploadField((fph:FileParamHolder) => handler), and
> nameForSubmitButton(() => JsCmd return). This may be one of those things
> that is better provided alongside Lift rather than as part of Lift proper,
> but I wanted to hear what people thought about it.

Sounds interesting but I don't fully follow what it does, does it
change the way Lift generates names for forms?

It's actually just a shortcut for the same fmap that's done for a string, file upload, or submit field, but returns a String that is the function name instead of any NodeSeqs.

> So, thoughts, feedback, things you definitely think shouldn't be in there?

I think you should add them all :) !

Sweet! :)

Thanks,

Antonio

[Antonio Salazar Cardozo]

On Saturday, April 7, 2012 3:04:20 AM UTC-4, Mads Hartmann Jensen wrote:

>  - We currently have a submitFormToIframe function that makes it so an ajax form with a file upload component can upload via “ajax” transparently to the developer and the user. I'd like to move that into liftAjax.js and, ideally, have some code that will automatically convert any generated forms with an input type file into iframed, fully functional ajax forms from a developer's perspective. Is this something people would like to see in Lift? As a user of the framework, my goal would be to make this completely transparent*.

It might be nice to avoid the iframe and use the JavaScript FormData API when present (seems to work in Safari, Chrome, Firefox, haven't tried IE)

http://hacks.mozilla.org/2010/05/formdata-interface-coming-to-firefox/
http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#interface-formdata

May try that. As far as I can tell, all you need to do is call getFormData() and send that? The iframe solution is great because it's minimum code for maximum impact, though.

 

>  - Equivalents for SHtml inputs that just provide a name for various types of fields. We use this in conjunction with knockout.js to bind input names client-side for Lift form management sent via JSON instead of as pure HTML. We have nameForStringField((s:String) => handler), nameForFileUploadField((fph:FileParamHolder) => handler), and nameForSubmitButton(() => JsCmd return). This may be one of those things that is better provided alongside Lift rather than as part of Lift proper, but I wanted to hear what people thought about it.

I agree this would be nice. Maybe instead of returning a string return an object like

trait FormElement {
        def name: String
        def html: NodeSeq
}

Interesting. In that case, wouldn't it make sense to make SHtml functions return that by default, maybe with an implicit conversion to NodeSeq so it can still be used normally in e.g. (NodeSeq)=>NodeSeq transforms and such? The purpose for the nameFor*s for us is that we don't need the HTML at all, that lives in our template alongside knockout bind expressions.

Thanks,

Antonio

[Mads Hartmann Jensen]

Yes, I would prefer to change the normal SHtml methods too but was afraid to suggest it due to the enormous breaking change that would cause ;) But 

yeah, might be able to fix that with an implicit :) 

Thanks,

Antonio

[Antonio Salazar Cardozo]

Definitely an interesting thought. I guess the only downside is we'd be generating NodeSeqs even in cases where they're completely unnecessary, but it would reduce the number of functions for doing these things.

Maybe this one is worth breaking out into its own, possibly larger, discussion come Monday when more people can give feedback?

Thanks,

Antonio

[Mads Hartmann Jensen]

On Apr 7, 2012, at 5:00 PM, Antonio Salazar Cardozo wrote:

Definitely an interesting thought. I guess the only downside is we'd be generating NodeSeqs even in cases where they're completely unnecessary, but it would reduce the number of functions for doing these things.

No I don't think you would :) As long as it's a method on the trait it won't do any computations unless you ask for the html.. right? 

Maybe this one is worth breaking out into its own, possibly larger, discussion come Monday when more people can give feedback?

I think that's a good idea yeah :) 

[David Whittaker]

On Sat, Apr 7, 2012 at 11:04 AM, Mads Hartmann Jensen <mad...@gmail.com> wrote:

On Apr 7, 2012, at 5:00 PM, Antonio Salazar Cardozo wrote:

Definitely an interesting thought. I guess the only downside is we'd be generating NodeSeqs even in cases where they're completely unnecessary, but it would reduce the number of functions for doing these things.

No I don't think you would :) As long as it's a method on the trait it won't do any computations unless you ask for the html.. right? 

Maybe this one is worth breaking out into its own, possibly larger, discussion come Monday when more people can give feedback?

I think that's a good idea yeah :) 

Actually, if you guys could elaborate a bit on what you're trying to accomplish here, I'd appreciate it. You need function ids, but you can't use S.fmapFunc because you also need the generated HTML?  I'm not sure what you are doing with the function ids, and wouldn't it be much less invasive to add a helper method to retrieve the function id from the generated NodeSeq?

[Antonio Salazar Cardozo]

Sorry, I'll give be a bit clearer with an actual example from our code base:

    def nameForFileUploadField(fn:(FileParamHolder)=>Any) : String = {

      S.fmapFunc(S.BinFuncHolder(fph => if (fph.length > 0) fn(fph)))((name:String) => name)

    }

It does use fmapFunc, it's essentially a shortcut to avoid running the HTML generation code. In integrating it, I was intending on piping the current fmapFunc stuff in SHtml helpers and the nameFor stuff through a common function to generate the proper holders and such and just modify what we return (name vs XML).

Thanks,

Antonio

[Josh Berry]

On Fri, Apr 6, 2012 at 9:57 PM, Diego Medina <di...@fmpwizard.com> wrote:
> Hi Antonio,
>
> They all would be great additions to Lift imho, some small comments below:
>
> On Fri, Apr 6, 2012 at 5:44 PM, Antonio Salazar Cardozo
> <savedf...@gmail.com> wrote:
>> There are a variety things in the OpenStudy toolbox that I'd love to move
>> into Lift as I have time, but I wanted some feedback on a few of them:
>>
>>  - We currently have a submitFormToIframe function that makes it so an ajax
>> form with a file upload component can upload via “ajax” transparently to the
>> developer and the user. I'd like to move that into liftAjax.js and, ideally,
>> have some code that will automatically convert any generated forms with an
>> input type file into iframed, fully functional ajax forms from a developer's
>> perspective. Is this something people would like to see in Lift?
>
> More and more often people ask how to do an ajax upload in Lift, so
> having a builtin way would be great.

So, this is something I just recently did on a side project I am/was
working. Reading that this is still a common issue, I question if I
did something dumb. The code is at
http://code.google.com/p/commuters-connect/source/browse/web/src/main/scala/com/commutersconnect/snippet/NewReport.scala.
The only twist I had to do in putting this on an ajax form, was I had
to change the "action" of the form such that it hit the rest service I
exposed instead of being javascript://. Am I messing something up in
that strategy? Only place I've found that this doesn't work right off
is on older android devices. Works on the newer ones just fine.

-josh

[Antonio Salazar Cardozo]

Hm. You don't happen to have this actually running somewhere? I've never seen file upload work via ajax without either FormData, Flash, or iframe retargeting in my experience. Certainly not on IE. Are you sure you haven't accidentally ended up with a regular form not submitting via ajax? Part of the reason I ask is that Lift's ajax submission stuff ignores the action attribute on the form field anyway, so by all accounts if you had an ajax form, your changing the action attribute wouldn't do anything.

Thanks,

Antonio

[Josh Berry]

On Sun, Apr 8, 2012 at 12:02 AM, Antonio Salazar Cardozo
<savedf...@gmail.com> wrote:
> Hm. You don't happen to have this actually running somewhere? I've never
> seen file upload work via ajax without either FormData, Flash, or iframe
> retargeting in my experience. Certainly not on IE. Are you sure you haven't
> accidentally ended up with a regular form not submitting via ajax? Part of
> the reason I ask is that Lift's ajax submission stuff ignores the action
> attribute on the form field anyway, so by all accounts if you had an ajax
> form, your changing the action attribute wouldn't do anything.

Apologies, I shouldn't have indicated I didn't have those things.
More that I lucked up and got David's example ajax test working inside
a lift:form.ajax with very little trouble. The jquery file upload
plugin is doing most of the heavy lifting, I believe. I just had to
change the action of the form to be a rest service returning what it
(the file upload plugin) is expecting. The rest of the form works as
expected.

That make since? I certainly still have a few spots that have been
ignored. In particular, I have not written something that will cause
any uploaded files to expire when the form expires. I was thinking I
could just use a weak hashmap for that, so that when the form is
collected, they could be as well.

[Antonio Salazar Cardozo]

Ah yes, see, jQuery File Upload plugin uses, in part, the jQuery iframe transport plugin, which retargets the form to an iframe. So it's really the same thing. There are plugins out there for it, no question, I'm just proposing we make it a core part of Lift so developers only have to worry about an external plugin if they want additional functionality.

Thanks,

Antonio

[Josh Berry]

On Sun, Apr 8, 2012 at 11:06 AM, Antonio Salazar Cardozo
<savedf...@gmail.com> wrote:
> Ah yes, see, jQuery File Upload plugin uses, in part, the jQuery iframe
> transport plugin, which retargets the form to an iframe. So it's really the
> same thing. There are plugins out there for it, no question, I'm just
> proposing we make it a core part of Lift so developers only have to worry
> about an external plugin if they want additional functionality.

Yeah, looking back I'm not sure what I was trying to say, honestly.
It just sounded like folks have had trouble getting file uploads
working in a lift:form.ajax and I wasn't sure if there was a bullet
heading my way or not. I see on the wiki there is special effort made
at making the entire form submit over an iframe, whereas I was able to
let the jquery plugin handle that. Looking at the wiki more, I am
guessing that I could have gotten away from writing a REST service
method for the uploads if I had followed the wiki? (My first google
for this showed up the example David put together, so I had the REST
part written before I realized you couldn't have more of a form around
it. I fiddled with changing the action on my own, as that was so
quick, before seeing the rest of the wiki.)

[Antonio Salazar Cardozo]

The real goal here would be to make it so you don't have to refer to the wiki at all, Lift just takes care of the basic need automatically. In cases where you need something more (e.g., upload progress or multiple file select), you would switch to, say, jQuery file upload, but the basic process of making an ajaxForm that has a file input in it would be taken care of for you.

Thanks,

Antonio

[Christopher Poile]

Hello Antonio, fellow Lifters,

I was wondering if you had eventually committed the nameForStringField and related functions? I tried searching your github and commits, but I couldn't seem to make the connection. 

And I guess connected to this -- would you or anyone else have some getting-started advice for the approach you've settled on with OpenStudy? I don't mean a tutorial or anything elaborate, but maybe just a few pointers about what to avoid and what to concentrate on when building this style of application in Lift, particularly when a lot of the client interaction happens client-side with Knockout.js (or something similar like AngularJS). I remember a few months ago you had mentioned that JsCmd was useful when starting OpenStudy, but that you had evolved from it when you started to use Knockout. I'm wondering then, what did you evolve to, and what should someone new to the framework prioritize learning if this was the end goal?

Many thanks,

Chris.

[Antonio Salazar Cardozo]

Hi Chris,

I never did, some further discussion means it's unclear whether or not that'll be going in.

Here's our code for the nameFor*s: https://gist.github.com/2639553 .

A brief overview of how we handle data pushing:

 - partialUpdates invoke a function called openstudy.event

 - This function takes an event name and JSON data to pass along with the event

 - jQuery handlers are set up for the various events to deal with the changes they represent

 - Data is managed in objects called DataHolders. These wrap most of their data in Knockout observables or observableArrays.

 - DataHolders and their properties are generally what is bound into the templates.

CoffeeScript code for DataHolder is at https://gist.github.com/2639589 .

You can get some superficial idea of how the relevant function ids are bound in by looking at the DOM on http://openstudy.com/study . Typically the submit functions that are sent down from the server are run with a manual setting of liftAjax.lift_uriSuffix; e.g.:

createGroup = ->

  liftAjax.lift_uriSuffix = "#{createFormInfo.groupPostName()}=_"

  createFormInfo.submitFn?()

  false

Hope that helps!

Thanks,

Antonio

[Christopher Poile]

Hello Antonio,

Thank you, that is a tremendous help. I need to do a _lot_ more reading to fully understand what you've just said. :) But now I have some direction. 

From inspecting your code, is it safe to say that you are using Lift as it is described in David's and Timothy's books (view first, snippets, comet actors, and so forth) for all the non-data-pushing view? In other words, I should just continue to work my way through the Lift books and online resources without worrying I'm spending time on features I'll never use?  (except for the obvious--Lift wiring is probably unnecessary if you're using Knockbackjs or Angularjs...)

Again, thank you, this list is a fantastic resource for newcomers like myself.

Chris.

[Antonio Salazar Cardozo]

Absolutely. Even the views as you see them there make sparing use of snippets (for example, for IE conditional comments and a few things that don't need to be pushed). On pages where we use knockout, the templates were evolved from view-first templates that were built using CSS selector transforms into HTML using knockout bindings. And, in the backend, we continue to use comet actors to power a large part of the site.

Glad to hear this is helpful, and feel free to start new threads if you have any more specific questions!

Thanks,

Anotnio