I have a Cmd-generated 6.0.2 application that is running at about 200 customers on-premise servers. I would like to allow the customers to select a base color and a text color, (e.g. #c0ffee and #facade), and call an API running on our server (not on a dev PC!), that takes the SCSS, sets $base-color:dynamic(#c0ffee) and $color:dynamic(#facade), generates the resulting CSS and returns that to the customer, where it is stored on the server alongside the app.
It is really easy to implement this by copying the whole project, including the javascript sources, to the server, calling sencha app build production, and then return the content of the generated CSS files. But since it's a server API, I would like to reduce the footprint, by not always compiling and then discarding the javascript, and at best, not even needing the javascript on the server.
It would be really nice if someone could tell me how I can, using sencha Cmd, generate a single SCSS file that contains all styles required for the app, such that I would only have to search/replace in that file the $base-color and $color definition, and how to, after successfully replacing it, call sencha fashion to only generate a single new CSS file from that SCSS file.
Related
Per the Meteor docs, I'm trying to determine which special folder to place non-app assets (ex. Photoshop design PSDs) in, so that they still get checked into source control but don't get wrapped into the eventual client or server payloads.
It feels 'wrong' to use tests/ for this purpose but the docs suggest it has the desired behavior. Can private/ be used similarly, or will its contents always get added to the server bundle regardless of whether your app code registers any Assets? (Or is there a better place altogether to put such files?)
Consider a project structure like this:
/YourMeteorProject
/YourPSDFiles
file1.psd
file2.psd
...
/YourMeteorApp
/.meteor
/client
/server
...
You can launch your meteor app from within /YourMeteorApp. Files that are not part of your application, such as your PSD files, are kept outside of the application.
I'm trying to create a really basic web app that lets a user upload an xml file with a form, runs an XQuery script which I already have written as a function, and returns the result. I have BaseX running on Tomcat, but for the life of my I cannot understand RESTXQ even though I have a lot of experience with complex XQuery scripts. The BaseX documentation has been no help (http://docs.basex.org/wiki/RESTXQ). What is the basic architecture?
From what I can see, its all keyed on this restxq.xqm file in the webapp directory. If you link to that directory it runs the .xqm file and this is mandated by a web.xml file. But it seems that all of the html sections are also stored within this restxq.xqm file. Wouldn't it make sense so store html sections in separate files for maintenance/reusability?
Also, for my file upload form, do I have the action attribute point to restxq.xqm? I can make the pages all static html since the app is so simple, but where is the index.html file go? This seems WAY more confusing than it has to be.
All,
Sorry in advance - I'm a total novice when it comes to ASP.net.
I'm working on a project that's fairly simple. I have single HTML page that collects input from the user. When the input is complete - the html page uses AJAX to post the data to a web service. That service receives the data, does some processing on it, then sends back a response.
The "client" part of this app is pure HTML/Javascript (not ASP.net), and is complete and works perfectly.
The "service" part of this app (MyHandler.ashx) is built using ASP.net. Technically - what it does is receive data from the AJAX post. It then uses Microsoft.Office.Interop.Excel to open an Excel spreadsheet, pass the users' inputs into that spreadsheet, then retrieve several calculated values from the spreadsheet, and returns those values in the response to the AJAX post.
Using Visual Studio VS I've got this whole process running locally on my PC.
When I "publish" the project - VS creates a ton of files. I sent those files to the team that manages the server; they deployed them, and voilà - it works. (The necessary Office interop libraries are installed on the server).
So - my question - as I make a few modest changes (e.g., validation, error handling) to the handler - MyHandler.ashx - which of those published files actually change? If i want to reploy - do I simply need to resend an updated version of MyHandler.ashx? Or, do simple coding changes to that file require changes to the DLL?
I guess my question is, generally - what's in the DLL? (E.g., is it a compiled version of MyHandler.ashx?)
More specifically - publishing my project creates the following files that I don't really understand:
Web.config
Global.asax (in my project, there's not much in here)
bin/MyProject.dll
So, if I make changes to MyHandler.ashx - can I simply reploy THAT file? Or, do I need to "publish", then "redeploy" thd dll? (By changes - I mean simple code changes, not decisions to include/exclude other external dependencies).
Sorry - this question must seem like nonsense to knowledgeable ASP.net developers. But, with other technologies I've used, things were clear:
If you're developing a Flash project, you write source code in .FLA files, then compile, then deploy the resulting .SWF files.
If you're developing an HTML/JavaScript/PHP project, you write those files, then deploy those same files
I'd trying to get a better understanding of what's what with ASP.net.
Thanks again.
The DLL contains the compiled code behind the ASHX file. The ASHX is just a service definition for an HTTP handler. When you make changes to the service (e.g. the code), simply issue another Publish like you did before and send the entire package.
But in short, when you change the code, the DLL is what's changing.
In Meteor is there a way to include a js file in another js file.
Specifically, server side and most importantly at start up.
The use case I am running into is for complicated Meteor.startups where I need to load quite a bit of data to the mongodb into a variety of collections.
In order to have different test scripts I have to have more than one file each with duplicate data.
So, is there anyway to have say a boostrap.js file that calls Meteor.startup and then is able to load different files in order to load up the test data?
Or can this be done in a different way through some kind of object?
By design Meteor will automatically include all the javascript files in the the entire project (except in the public folder) but only segregate them between the server and client.
You could create objects in separate files and just use the functions or objects whenever you please, they should all be available at startup.
Try using my module loader made for use with Meteor. It's very similar to AMD: https://github.com/matb33/meteor-smd
Copying a static website, i.e., HTML, CSS, JS is very simple.
Copying a dynamic website, i.e., is difficult due to the server-side scripts.
I'm concerned about cloning any meteor app as most of the server-side scripts are eliminated and the only thing which needs to be copied is the database, the schema can be easily obtained from the meteor live app and data can be easily scraped from the existing meteor app.
If a successful meteor app can be easily cloned, no one would prefer to develop an app on meteor.
Is there a way to stop cloning an existing meteor app?
Well, technically a meteor app can be cloned it depends on your directory/file structure & whether you're using it in development mode. If you're using one file and this sort of structure to seperate your code:
if(Meteor.isClient) {
}
if(Meteor.isServer) {
}
Because this file would be sent down to the client so someone can fetch it.
So it might be better to move to this structure
/client - Place stuff in Meteor.isClient in a new js file
/server - Place your server side code in a new js file
/public - Place other public folder stuff
So no one will see the server side scripts, so they can't clone the backend of your app.
Production mode/Dev mode
In addition if you run your Meteor app in 'production mode' the Javascript is packed, handlebars & handlebars templates are precompiled.
In my opinion, it might be actually harder to copy a Meteor app to the previous types of web apps because HTML is rendered on the client side, fetching the html files will actually get back empty html files, if you even prettify the large JS file still leaves back precompiled handlebars templates. In addition files are merged into one!
So thats when it comes to cloning it to another meteor app. Even if getting the client script is available (as with any other stack) there are even more hurdles with Meteor when it comes to replicating the server script:
DDP
Attempting to clone it to a PHP/Server side script stack might be even harder because POST/GET aren't even used, DDP is used instead.
Schema
Width regards to the schema, you can control what the client sees via Meteor.publish, so they won't actually see the whole schema