How to handle positioning and linked files?

I’m working on my first WebSDK Control, a CKEditor implementation. I’ve got it basically working, but I’m having a couple of issues.

First is with positioning. I didn’t find any good examples of how to get control positioning right. I’d like to be able to position it in the IDE like a regular control and have the lock buttons work, and the top, left, width, and height all work. So far I’ve figured out I can get the top, left, width, and height using, etc in my code. That seems to work OK. However, I have not figured out how to adopt the lock styles properly.

For instance, when having on the top center lock selected the positioning styles change using percentages and margins, etc. How can I find out the lock styles to apply, or even when they are applied. I didn’t see anything in the docs for this, or maybe I just didn’t realize what I should be looking for.

Also, another thing that I am not sure of is the way I load the local config files. CKEditor uses plugin.js files and a config.js file for custom configuration. What I’ve done is simply create string constants with the contents of the files I want to use and print them in the handleSpecialURL method on the app. It seems to work well, but I would like a simple way to do this that is self contained in the SDK control. I’m just not sure how I should accomplish that.

It seems like it would be cool to be able to have some special url for webcontrols since this will probably be a common need. Maybe there is already a good way to handle this.

Create a div with an ID attribute which matches the ControlID property and your control will get all of the positioning for free.

You can use webfiles and the htmlheader shared method for your Libs.

Thanks Greg. I’ll give those a shot. You don’t happen to know of an example that makes use of either of those methods do you?

Look in the WebSDK folder (inside Extras) there should be one in there.

I got the positioning working, but I’m still a little lost on the webfile thing. So in the library there are references to other files in the scripts. It expects for instance the language files to be in a subdirectory /lang/en.js or similar. Using webfiles I presume I would have to somehow fix all the references in the files to reference a unique webfile link that would be created when I create the webfile.

Is there a better way to do this, or should I file a feature request for something to handle this. Seems like it would be a common problem when using javascript controls.

For the files that are common to all instances of your control, create a private shared property which is an array of WebFile. (For items that change from control to control or session to session, just use a non-shared property). For each file that you need to be available to the browser, create a Webfile, set its Data property, mimetype, filename, etc and append it to the array. You can get the url directly from the WebFile after you’ve set all of the properties. If they’re big, make sure you create them on disk and set the inMemory property to False when loading them.

Come to think of it, you could probably use Dictionaries instead of arrays if you thought you’d need access to them again later and then refer to them by name.

So maybe I am missing something, or there is a miscommunication. The problem I’m trying to solve is that the javascript library I am using is setup to be loaded on a server in a directory and in that directory are other folders with files inside. The specific example in my current use is files paths like the following.


So in my testing with webfiles I get paths like…

So what I’m struggling with is do I have to maintain my own version of the js project that replaces links and code references to files with some the webfile paths that are generated on the fly when the webapp loads. It sounds doable, but not ideal.

What I would like is a way to handle this type of use case, and it could be generalized I think to handle other types of static files, so that I can do something similar to what I’ve done now with the api URL.

[code]Function HandleSpecialURL(Request As WebRequest) As Boolean
dim path as string = Request.Path

select case path
case "lineheight/plugin.js"
  request.Print kLineheightPluginJS
case "lineheight/lang/en.js"
  Request.Print kLineheightPluginLangENJS
case "config.js"
  Request.Print kCKEditorConfigJS
  return false
end select
return true

End Function[/code]

I’d really like a way to just take the root folder with all the js files in it and throw it somewhere accessible by the app, assign it prefix path based on the controls namespace and control name and it would just work.

Maybe I’m overthinking this or missing some aspect of the webfile solution that would make it a better solution?

The reason to maintain your own WebFiles is portability. If you don’t care about giving away your control then doing it all in HandleURL or HandleSpecialURL is just fine as you’ll be the only one doing it.

Well, maintaining control is not really a concern I don’t think. If I’m wrapping something like CKEditor or some JQuery control, I don’t have control anyway. It’s downloadable on github. My concern is not having to rewrite the JS code to maintain my own version. I’d prefer to run it without modification. That makes it much easier to update if there’s a bug or security issue, just download the new version and replace the files.

I’ll think about it some more and see if I can come up with a coherent feature request.

I created a feature request. I’d appreciate any comments or thoughts on it.


Looking around in feedback I found two requests that are very much trying to solve the same problem. One was actually mine from a couple of years ago, and the other from Brock Nash who’s posted a lot of help on custom controls. My experience mirrors his almost exactly. I think the only thing different is that I am asking for a more generic solution that would be useful outside of custom controls as well.

If anybody else thinks this is important, maybe you could give it some points in feedback. I think it would help a lot of people building web apps.