Barry there may be another way of working around this.  Though the “new record” models do prepopulate an ID field,  they do not prepopulate any of the other required / read only fields.  You might get the outcome you are looking for if you put your conditional rendering in place on whether one of those fields is blank.  If “Created date” is blank you can pretty safely assume that it is a new record and render as a “new record” page. 

Let us know if this works for you. 

Cheers!

Hey Rob -

Thanks for the reply.  The CreatedDate == null trick (option #1 from my original list) works and it’s what we’ve been using in our pages.  Really where I was going with this is starting to provide some ideas about enhancements to Conditional Rendering (there are some posts already in the community and I have a few others queued up :)) that would provide substantial benefit.

In the case of new records, while this can be achieved today, providing a more explicit mechanism is really the thinking here.  It would make it more intuitive for skuid developers, especially for someone new to skuid, as well as providing a more reliable approach (understanding that CreatedDate should always be null for new records and theoretically that should never change in future releases).

Thanks!

Hey Rob -


With the new Summer '14 release, the ability to conditionally clone a model is exposed and is extremely powerful. One of these benefits is that we can now develop pages that handle “New” and “Clone” as well as “View” and “Edit.” In short, one page instead of multiple.


Unfortunately, one challenge that I’m facing to accomplish this without code is detecting a “new” record since on a Cloned model, CreatedDate has a value but the record is New.


Any thoughts on how to solve for this and also if you guys are planning on expanding the “conditional” rendering options to include IsNew and other types of capabilities (call a snippet, formulas, url param, field from another model, etc.) in a future release?


Thanks!

Barry - we’ll give this some thought.  Nothing comes immediately to mind. Except for the snarky thought that you are trying to have your cake and eat it too.  But then,  so would I - so there… 

Hey Rob - Well I do like cake Thanks!

Hey Rob - I spent a little more time on this and think I have a viable solution. Admittedly it’s not the most elegant but unless you feel otherwise, it should achieve the desired result without any consequences to other underlying structures, etc. In short, I’ve created a snippet that detects whether or not a row is new and also if the page is in a “clone” mode. If yes, the snippet removes the CreatedDate and CreatedById from the row and then re-renders the component. The snippet is called via an inline snippet in the skuid ready function. The downside is that this solution requires code and also intimate knowledge of which components have conditional rendering. That said, it appears to work as we need it to (further testing and validation is still pending on my end :)). Here’s the snippet: if (skuid.model.isNewId(accountRow.Id) && skuid.page.params.id && skuid.page.params.clone) { var updateFields = { ,CreatedDate: null , CreatedById: null }; accountModel.updateRow(accountRow, updateFields); skuid.component.getById(‘accountfieldeditor’).render(); } A couple of questions: 1) Any feedback on approach approach? Potential improvements? 2) When updateRow is called, the CreatedDate & CreatedById fields do not automatically update in the Field Editor however if I update a field like “Description” it does automatically update. Any reason why CreatedDate & CreatedById do not automatically sync with the field editor that displays those fields? The fact that it does not forces an explicit call to component.render(). 3) As I understand it, cloned records are created on the client. I first attempted to set a model action using the new action framework (have I mentioned how awesome the action framework is?) for new row created and then call the above snippet from that action. Unfortunately, it does not appear that the new row created fires when the initial data is loaded in to the model. I also tried to trap for the event row.created but that too did not fire. I’m assuming this is by design? Assuming yes, thoughts on having these events fires even on initial load in a future release? A few further thoughts on expanding conditional rendering functionality: 1) For “IsNewId” capability, my thought is you could consider adding this as an operator on conditional rendering. There is already logic that exists for the available operator choices so the “isNewId” operator could only be displayed if the field selected is an Id field. This approach would allow you to provide isNewId capability using the existing structure of conditional rendering and would avoid all the code from above. 2) Since I really do love cake, taking the above one step further and as an initial feature, another operator could be added that would call a snippet. This of course, does come with some risks as customers could get pretty crazy in a snippet and since this impacts UI rendering performance, this could lead to negative consequences. That said, by offering a “call snippet” operator, customers (at their own risk of course and understanding the ramifications) could do anything they want and then just return true/false from the snippet for skuid to evaluate during analysis of conditions. Having a “call snippet” operator would allow for things like computed value analysis, checking other models or even custom rolling the isNewId by just calling skuid.model.isNewId(row.id). Possibilities would be endless Thanks!