I'm implementing custom user authentication in a Meteor application (so no use of accounts-ui). I have only done 'meteor add accounts-password' and registration/login are working as expected. In lots of tutorials, I also read they are doing a 'meteor add accounts-base' which is something I didn't do specifically, yet it is working.
Why would I need 'accounts-base'? For what functionality?
accounts-base is a dependency of accounts-password, so it's alteady included in your application, there's no need to add it separately. It provides the basic account concepts (Meteor.users collection, for instance) that accounts-password relied on.
Related
So, I have inherited a Laravel 8 project from the previous developer who decided to leave for a greener pasture. And I see all this blade components everywhere, (x-this, x-that) and I have also created a few. I have used make:component command and I can see the components being generated both in `App/Views/' and 'resources/views'. That's great.
Now, there are other components, which the previous developer have created that I can't figure out where where these components are being registered at. They are not in the App directory, not in the service provider boot, there's no custom vendor in the composer.
So, I think the obvious question is, where else should I look for?
Those may be anonymous components. Anonymous components does not require any registration. So check resources/views/components folder.
For more info:
https://laravel.com/docs/8.x/blade#anonymous-components
I need to implement a new accounts package with trakt.tv service via OAuth2.
How can I use the source of accounts-facebook or other already implemented to create my own?
This already has been answered here, in resume, you need to create a
local package
and take a look into the meteor-accounts-stripe to get the idea about how to create a new OAuth package
If you check out the Meteor Packages at GitHub you can reverse engineer a solution.
Also see the Accounts project page at Meteor.
With the latest Meteor version 0.5.9 I've been experimenting with the appcache package, and really like its functionality.
I used meteor create --example leaderboard and then meteor add appcacheto test out the behaviour, and the page even loads when the server is not running at all! Super cool!
However, the database does not seem to be cached? When the server is not running
Players.find().fetch()
returns
[]
This is quite a showstopper for me, as I'm making a notes app where the notes need to be available offline as well. Am I missing something or is there an alternative method of getting database data when offline?
Look at the Ground:DB Package for this use. This package makes client side caches of subscribed collections.
https://atmospherejs.com/ground/db
Example of a collection that will get populated by Meteor subscriptions (subscribe call required separately)
localCollection = new Ground.Collection('mongoName');
Example of disconnected Collection (so you have to populate it yourself)
disconnectedCollection = new Ground.Collection('localName', {connection:null} );
The appcache package doesn't cache your data. See the docs:
The appcache package stores the static parts of a Meteor application (the client side Javascript, HTML, CSS, and images) in the browser's application cache.
[...]
(Note however that the appcache package by itself doesn't make data available offline: in an application loaded offline, a Meteor Collection will appear to be empty in the client until the Internet becomes available and the browser is able to establish a livedata connection).
At this point the appcache package is purely meant to improve loading speed of your app by caching static resources. See the meteor wiki:
The appcache package is only designed to cache static resources. As an "application" cache, it caches the resources needed by the application, including the HTML, CSS, Javascript and files published in the public/ directory.
I'm developing a product for Plone, say foo.core. Besides that core product, there are also several related products. like foo.optional. These releated products may be available in the instance and if they are available they may be installed (in other words: I cannot assume the code is available or, if it is, should be used).
These related products may override settings made by foo.core (e.g. in a Property Sheet). This works fine, but if I reinstall foo.core, the default settings are back. What I'd want is to somehow automatically reinstall foo.optional when foo.core is reinstalled in the QuickInstaller.
The solutions I could come up with are:
When foo.optional is installed, it
registers itself with foo.core. The
latter, foo.core, will handle the
reinstallation of all registered
products when the core package is
reinstalled.
The foo.core package
triggers an event which other
packages, like foo.optional, can
listen for. An event handler will
then trigger the reinstall of
foo.optional.
Make sure that foo.core
doesn't overwrite any settings that
may have been customized later by
other products.
Perhaps there are more alternatives? What would be the 'Plonish' approach?
Edit: I know that using upgrade steps might be better than reinstalling the product. However IMHO the problem remains the same: the Generic Setup profile used for the upgrade step might have a setting that is modified in the Generic Setup profile for the foo.optional package.
So using upgrade steps makes my problem even harder: how should I determine whether the upgrade step of foo.core means foo.optional should be reinstalled/upgraded? (The assumption is still that foo.core in principle does not know about foo.optional.)
The solution to your problem is much easier than what you propose:
We do NOT reinstall products like we did in the past when the product is updated. Reinstalling a product will cause your generic setup profile to be reapplied which is why you get your settings overwritten.
Instead you now provide upgrade steps. For instance if you change your profile version from 2 to 3 then you would have:
<genericsetup:upgradeStep
title="Upgrade foo.core from revision 2 to 3"
description="Adds stuff"
source="2"
destination="3"
handler="foo.core.upgrades.two_to_three.addStuff"
sortkey="1"
profile="foo.core:default"
/>
Inside the upgrade step you can do what you like, even re-run individual import steps.
If your product upgrade does not involve changing the GS profile, do not increment the version in metadata.xml. In that case you obviously don't need an upgrade step either.
I suspect you are making things much harder on yourself by involving Plone's add-on installation story (which is complicated by "old" and "new" technologies living side by side). I would take a step back and think more about the plugin system you are trying to design/implement, and avoid including Plone until you absolutely have to [1].
You also might consider using entry points to implement at least a portion of the plugin system:
http://wiki.pylonshq.com/display/pylonscookbook/Using+Entry+Points+to+Write+Plugins
[1] Assuming Plone is a strict requirement and that you are building a content-management-driven application, else you should probably be using Django or Pyramid
Install/reinstall doesn't make sens in the context of an add-on. The vocabulary has been change to activate/unactivate but it is not again enough to understand the situation.
You have a 'setup' where you apply a configuration profile. Apply again and again a configuration profile doesn't make anything except broke existing configurations.
This is why every body will reply to this question by use upgrade step. We don't trigger profile on reinstall, we upgrade add-ons when the setup profile has some changes.
So if you are in a case where settings added by foo.core are changed by foo.optional you can do the following.
With the new plone.registry you can add a handler to the IRecord related events:
add
edit
remove
Consider the documentation:
http://pypi.python.org/pypi/plone.registry
I have done some code related to this where I want to rebuild css registry when some settings has been changed:
https://github.com/collective/collective.jqueryuithememanager/blob/master/collective/jqueryuithememanager/registry.py
How can I able to find the usage of default tables available in drupal.
Is there any documentation available?
For example: there is a table called node. I need to know what is the usage of it and how it acts.
Any suggestions or answers will be helpful and grateful.
Your question is not very clear (the term "usage" is quite ambiguous), but you could install the Devel module. After setting it up it will show, for every page loaded (home page included), which SQL queries are run.
Every module can add tables to the database. A default Drupal install uses core modules, either required ones or those installed as dependencies of the default installation profile. These modules install their own tables.
Each module declares its tables in its implementation of hook_schema. The Schema module use the information from the implementations of this hook to provide a schema documentation.
Most of the time, you shouldn't directly access the database but use the API provided by the modules managing the data. Tables are usually considered private for their modules. New release of a module may change its schema in an incompatible way. Using API is much safer. Unfortunately, sometimes database access is the only option. In these cases, implementation of a data access layer between your code and the database is advised.