I've added some static assets to dropwizard; i'd like to be able to programatically modify them occasionally (say, rename/copy the files, etc...)
does dropwizard provide a quick and easy way to get access to them? (can't seem to find it in any of the docs or while browsing through the libraries)
By default your AssetBundle will access things under your resources. I.e. if you want to modify them in runtime it might be a bit tricky.
However, there is a plugin that allows you to map external assets:
https://github.com/bazaarvoice/dropwizard-configurable-assets-bundle
Saved for last, I would like to ask why you would want to do this? It doesn't seem like a good idea. Wouldn't it be better to create more dynamic content?
Related
Active Storage stores uploads in a file structure like so:
This is great if the rails app is the only software that needs to use these files.
But what if the app simply serves as a means to upload the images to S3 so that some other (completely separate) service can consume them?
The problem being, other developers wouldn't be able to make any sense of the directory and files, since they're labelled in a way rails can understand, but which a human cannot (e.g. what does folder named "O2" mean?).
Is there some way to ensure uploads are stored in a human-friendly way? e.g. each folder could be a user_id, with their assets inside? (or similar)
As far as I remember, you would have to implement an own service that somehow replace the key used to something else (e.g. S3Service), or patch ActiveStorage to create the key itself in a different way. I am not sure that this would suffice though, as the key is most likely used for other critical functionality outside of the Service.
Alternatively you might poke in ActiveStorage::Blob to fiddle with the key. That said, ActiveStorage does not support what you'd like out of the box and you would have to take the risk of messing with its internals.
A solution to the problem (but not answer to you question) might be implementing an API as outlined in the comments to your question.
It is very easy to create tickets on JIRA with almost no restrictions - which is why I am wondering if it is possible to force some kind of template or other limitation so that people create tickets with required fields.
I am unaware if this is possible and Google doesn't bring up much
The easy answer is yes, but there is a lot involved in creating custom request views that require admin access. You may find the following information helpful...
https://confluence.atlassian.com/doc/create-a-template-296093779.html
Field Configurations (which are applied through a Field Configuration Scheme) allow you to make specific fields required for a given Issue Type in a given Project.
See: https://confluence.atlassian.com/adminjiracloud/changing-a-field-configuration-844500798.html
You can do this type of restrictions and also change the aspect of the screen the users interacts with by using the Script Runner plugin, in particular by using the Behaviours feature of such plugin. You can also write Groovy code to customize almost every aspect of the form and do input validation/templating.
I'm currently building a web app (atop Ruby on Rails), which will let users style their own areas (personal blog pages), and was wondering what are the best ways of accomplishing this?
I think Liquid for templating would be good, but how would you handle styling? My aim was to have a DB field associated with each blog dubbed "style" which will store a custom stylesheet, is this the best approach?
I've tried it so far with the "sanitize_css" helper method, but it just strips the "#stylebox" tags out, meaning nothing is displayed.
Any ideas?
Thanks.
Currently I'm also working on almost a similar requirement as you do. I'm also trying to create a CMS for users to add pages, style them etc..
My Approach as follows
each user will have his/her subdomain. (I use a before_filter to get the current users subdomain and load his/her website)
About styling, I prefer to have the style sheet as a physical file. Given that your method will have the more flexibility of editing the style sheet, I dont like the idea of having the stlesheet code on top of my page. Insted, I allow users to load their styleshets (Using paper clip)
So when the site loads I will get the css paths from the DB and load the stylesheet from the path.
Later I'm planning to read the file and load it to a textarea so that users can edit their stylesheets and when saving override the existing file;
For layouts i use liquid as well
cheers
sameera
I would honestly allow themable elements on your page, and then store each of those style rules as a field (or conglomerate them into one giant field) in the database. Enforce some validation to ensure that they don't use any funny business (if they're only coding for specific div's, they shouldn't need to use any curly braces.)
Then generate the CSS on the fly.
The reason? If you ever want to serve up ad's on your site, and you allow them to just upload the entirety of their CSS, they can easily turn off visibility on the ad div.
I think it's "safer" to control what they're allowed to theme; sure more advanced users will get ticked. But do you really want to be the next MySpace? ;-)
if there is too much of code then serialize the data and store it as text in db.
That would be much better i think
If your going to allow areas for users to have complete control over their CSS, then I would probably avoid the database altogether and use a structured file system approach. You could create a sub-domain or folder for each user that contains a main.css. This also allows you to scale well as features grow for your user (pictures, etc.)
With that said, as Robbie mentioned, you might want to consider limiting what styles a user can and can not control. Otherwise, you would probably find things getting out of hand quickly. For this approach, you would probably want to use the database for storing property values of the elements that can be modified.
I have 2 Symfony applications (1 using 1.2.x, another using 1.4.x and both using Propel) that need to share some specific session information. Although I have no experience with memcached, my sense--after some reading--is that it may be able to serve as an external (FAST) repository that each app could read and write to. Unfortunately, I can't find much information about how to use it with Symfony in any capacity, much less in the quasi-cache, quasi-messaging server I'm envisioning.
My questions, I suppose, are:
Am I mistaken in believing that memcached be used in this manner and access by multiple systems?
How can I configure Symfony to access a memcached repository?
Thanks.
This explains one approach fairly well (you don't need the view cache stuff, just the second half about making a singleton available and configuring it):
http://dev.esl.eu/blog/2009/06/05/memcached-as-singleton-in-symfony/
edit: now 404, but still available here
You can then use:
sfMemcache::getInstance()->set()
and
sfMemcache::getInstance()->get()
(same as the methods here as sfMemcache subclasses Memcache).
As long as both apps point to the same memcache, you should be able to share data between them like this.
I am looking at implementing URLMapping for a personal project. I am already aware that solutions exist so please do not answer suggesting I should use one.
What I want is to harvest the opinions of fellow developers and web users on URL mapping implementations. Specially I would like you to answer:
Which is your favourite implementation?
What do you like about your favourite implementation?
What do you not like about your favourite implementation?
How would you improve it?
I would like you to answer from two points of view:
As a developer
As a user
I would be grateful for any opinions on this matter, thanks!
I've only worked with django's URLConf mechanism. I think the way it relies on the urlpatterns variable is a bit flimsy, but I like its expressiveness in specifying patterns and dispatching to other url configurations. I think probably the best thing is to figure out your URL scheme first, and then try out a couple of solutions to see what matches best. If you're going hard-core REST using the full complement of GET/POST/PUT/DELETE, and checking the user agent's Accept headers, and all that, django will, by default, have you splitting your logic between URL config files and view files, so it might not be the cleanest solution.
However, since it's all Python, you might be able to do some more complex processing before you assign to urlpatterns.
Really, you want a system that does what you need. Your URL scheme is your API, so don't compromise on it based on the tools you use. Figure out your API, then find the tools that will let you do that and get out of your way.
Edit: Also do a google search for "URL scheme design." I found this without much effort: http://www.gaffneyware.com/urldesign.htm. Not comprehensive, but some good advice gotten from looking at what flickr does.
Well, I should have noticed the url-routing tag shouldn't I? :-) Sorry about that.
jcd's experience mimics mine - Django is what I use too.
I like the fact that the routes for an app reside within the app (in urls.py) and can just be included into any projects that might make use of that app. I am comfortable with regular expressions, so having the routes be specified in regex doesn't phase me (but I've seen other programmers scratch their heads at some more uncommon expressions).
Being able to reverse a route via some identifier (in Django's case by route's name) is a must. Hardcoding urls in templates or controllers (view in Django) is a big no-no. Django has a template tag that uses the reverse() method
The one thing I wish I could do is have the concept of default routes in django (like Rails does or even Pylons). In Django every route has to map to a view method, there is no concept of trying to call a certain view based on the URL itself. The benefit is that there are no surprises - your urls.py is the Table of Contents for your project or app. The disadvantage is that urls.py tend to be longer.