Hi i was wondering if there is a module for nodejs which allows for simplistic widget creation in combination with mongoose as a datasource to create nice JQuery library (such as dojo or YUI) widgets.
for example when i setup my schema it would be nice to do something like (note code not runnable just pseudo)
var carSchema = {
carname: "String",
registration: "String",
mileage: "Number"}
methodCallback = function() {
car.find({}, ....) {
return results;
}
}
model.register("car", carSchema);
res.send(model.createWidget("listview", options, methodCallback()));
where createWidgets returns the html list view code and paging for the cars from the result i return in my callback. it would be nice if it integrated with REST so if i delete an item from the listview then it actions this on a connection to another method.
basically i want to try and remove all the difficulty of populating, deleting, updating, a widget on client side development.
"remove all the difficulty of populating, deleting, updating, a widget on client side development."
seems not very realistic as you always have to specify some specific CURD logic based on your needs.
For pure front end part, you may try AngularJS, which provide easy to use RESTful CURD service http://docs.angularjs.org/tutorial/step_11
if you are into more giant framework of full stack javascript (may not be Nodejs, Mongoose, Jquery widget), wakanda http://www.wakanda.org/features/studio may have something you are looking for as provide some widget integration with datasource.
Related
i am currently in a situation, where I am not able to fully test one of my components, because it renders a fluentUi DropDown and I have trouble to test if the correct items are bound to the dropdown.
What I wanted to try is to mock the fluent ui DropDown, but I do not get very far.
As far as I understood, it should be possible to mock a node module like this:
let module = require.requireActual("#fluentUi/react");
module.DropDown= jest.fn((props: IDropDownProps) => { return <>... some content</>; });
jest.mock("#fluentUi/react", () => { return module; });
But this does not have any impact on my tests. Am I on the right track or did I misunderstand something?
Thanks
I have investigated on this topic a bit more and ended up publishing a little example, where I am mocking the ui fabric modal.
It works fine. The mock only renders its properties, so I can assert within the snapshot, if the real life Modal gets consumed correctly.
https://github.com/Link631/MockingModulesWithJest/tree/master/mocking_with_jest
We try to build an application with a few tabs. As reference-project we use that example: http://slodge.blogspot.co.uk/2013/06/n25-tabs-n1-days-of-mvvmcross.html
To get the ViewModel-instances we need to create the tabs, we used the "HomeViewModel"-pattern as mentioned in that post: Create View Model using MVVMCross built in factory?
What I don't like at this approach is the initialisation of ViewModel's with "new". As far as I understand, it skips the whole ViewModel-Lifecycle (https://github.com/slodge/MvvmCross/wiki/View-Model-Lifecycle) which we really like. In our current project, we'd like to use the "start()" lifecycle-method, but it's never called due to initialisation with "new".
What worked for us was to go that way:
var loaderService = Mvx.Resolve<IMvxViewModelLoader>();
var vm = (UserListViewModel)loaderService.LoadViewModel(new MvxViewModelRequest(typeof(UserListViewModel), null, null, null), null);
So my question: Is that the way to do the job or is it just a dirty workaround and there is a much better solution?
Update: We came to that solution:
CreateTabFor<SettingsViewModel>("Settings", "settings");
//This method loads the ViewModel
private UIViewController CreateTabFor<TTargetViewModel>(string title, string imageName)
where TTargetViewModel : class, IMvxViewModel
{
var controller = new UINavigationController();
controller.NavigationBar.TintColor = UIColor.Black;
var viewModelRequest = new MvxViewModelRequest(typeof(TTargetViewModel), null, null, null);
var screen = this.CreateViewControllerFor<TTargetViewModel>(viewModelRequest) as UIViewController;
SetTitleAndTabBarItem(screen, title, imageName);
controller.PushViewController(screen, false);
return controller;
}
The 'viewmodel lifecycle' is an area of conflicting interests in MvvmCross. The root cause is the conflict between:
viewmodel's which are just the models for any view
viewmodel's which are specifically used within the 'ShowViewModel' navigation process
For simple 'whole page' User Experiences, the C-I-R-S viewmodel lifecycle is easy to support and to ensure it gets consistently used.
However, as soon as the user experience starts to merge in tabs, flyouts, hamburger menus, dialogs, split views, etc then:
the developers sometimes want to control viewmodel lifecycles themselves
it's not as easy for the framework to ensure that view models are always created, activated and tombstoned/rehydrated consistently
Personally, I like your approach - of trying to ensure all viewmodels are independent and all constructed the same way - but MvvmCross doesn't force this approach on all developers.
Specifically for tabs, most of the existing examples do use the 'owned sub-viewmodel' pattern that you've identified.
However, it should be relatively easy to implement other mechanisms if you want to - just as you already have.
In particular, you can:
use the loaderService directly - getting hold of it via Mvx.Resolve<IMvxViewModelLoader>();
use ShowViewModel with a custom presenter to create both views and viewmodels - the beginnings of this is illustrated in that N=25 video but you could take it much further and actually add the tabs in response to ShowViewModel calls.
use alternative calls to create the child tabs and their viewmodels inside the Views - e.g. where the Touch sample currently calls
var screen = this.CreateViewControllerFor(viewModel) as UIViewController;
this could easily be replace with something like:
var screen = this.CreateViewControllerFor<ChildViewModel>() as UIViewController;;
(or one of the other overloads from MvxCanCreateIosViewExtensionMethods.cs)
One repo where I know some users have taken some of these ideas and played with them is the Sliding menu repo - I think they have chosen to use this.CreateViewControllerFor<TViewModel> to create their view models. This may or may not be the way you choose to go - but it might be of interest for you to experiment with.
I am new to web programming and of course to YUI.
I tried using the overlay, chart and node-menunav.
Wanted to know if there is any option of creating these widgets using dynamic data coming in JSON format and updating the widgets as the new data comes in?
For us all the properties will come in JSON data from server and then using that data we need to render menubars, charts, property browser. Now i am not finding how to proceed with this requirement.
Thanks.
There is no default way of syncing widgets via Ajax. The only widget that comes by default with ways of updating its data is the DataTable widget. For the rest, and even for DataTable's attributes, you need to do it yourself.
However, if the data and widgets are complicated enough, you should consider using the YUI App Framework. The combination of Models and Views will help you a lot for creating complex layouts with widgets. Model will give you a way to link attributes to a JSON backend easily, specially if you're using a RESTful API endpoint. And View will give you tools for setting up the markup and reacting to events.
The Model's load and change events will let you know when the data updates. So in your view you'll be able to react to these events and set the corresponding attributes in your widgets:
var MyView = Y.Base.create('myView', Y.View, [], {
initializer: function () {
this.get('model').on('change', this._updateWidgets, this);
},
_updateWidgets: function () {
var model = this.get('model');
this.someWidget.set('someAttr', mode.get('someAttr'));
}
});
But as I said there is no right way of doing this. You can use whatever technique you like. The App framework is just a set of basic components that you can use to structure you application. It's designed for flexibility so it can accommodate many ways of using it. Other ways could use IO directly or use DataSources combined with Widget Plugins. This is a question with many correct answers.
I am writing an app with node.js and coffee-script and coffeekup as template engine. I have a form where I'd like to enable or disable a button depending on whether there are values in some input fields. I am wondering whether there is a straightforward mechanism like in Sproutcore or Ember, where just a binding will do. How should I go about it?
No, there is no such binding out of the box. You have to either implement something like Ember, Knockout or Serenade.js, or roll it yourself. If it's just this one form, I would just have a small script (jQuery below):
function validateForm() {
// Check if form fields are valid, return true if valid, false if not.
}
// Update the disabled attribute on a button inside "formId" anytime an input field is changed.
$("#formId").on("change", "input", function(event) {
$("#formId button").attr("disabled", !validateForm());
});
I'd like to build suitescript implementing same functionalities with standard function.
For instance on item detail page (List/WebSite/Items) clicking view button of any non inventory item, you could find out Convert To Inventory button.
Thanks to inspect that browser support, it shows some as follows
I want to build script that archive same functionalities like getNLMultiButtonByName('multibutton_convertinvt').onMainButtonClick(this);return false; but it throws error like getNLMultiButtonByName is not defined.
I want your help.
Regard
Probably you're looking for something similar
function onLoad(type, form, request){
if(type=='view') {
form.addButton('custpage_button','Custom Button',"getNLMultiButtonByName('multibutton_convertinvt').onMainButtonClick(this);return false;");
}
}